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important than ever before to get a head start on competition* 

for jobs. • , * ^ . * 

3> .DETAILED EXAMPLE ^ 

L^t us follow^ through for a moment how an actual job lead 
would be processed- The procedure is pretty much the same regard- 
less of Whether the lead is classified ds teaching or administration 

♦ 

on an elementary, secondary, two-year or four-year college level 
or falls into a general category such as acpount^nt, computer . 
programmer, etc. . ' ' - ' • 

3.1 Th^ Job Vacancy - Let- us assume that a reqXiest has come in » 
from a high school principal who' is looking for 'someone who: 

• " a.^ ■ seeks a TEACHING' position in SECONDARY education' 
in FR?N9H- . ■ ■ ^ ' - ^ " - ^ 

b. has a, MASTER'S degree ' , . t 

c. - is willina =to work in SYRAOJSE, New., York ^ . 

d. will be available for erppdoyraent in DECEMBE>R 
"e. is willing to accept $10,(H)0 per year 

■ f . has minimum related work experience, of TWO years | 
A member of the Placement staff can very, quickly type into the 
'terminal .keyboard the following mess&ge: 

SEL' PCS T S pre; DEC MAS LOC'SYR AVA DEC SAL 10 EXP 2 
This^is'thQ shorjfchand notation describing the job. , The bperatot 
' cbuld also ent^r a longhand version o-f the same search request 

_^a9 follows: • 

■ SELECT p6siTIQN =• TEACHING, SECONDARY) FRENCH 

DEGREE = MASTERS, LO'CATION » SYRACUSE ," AVAILABILITY = 
DECEMBER, SAUVR^ = 10,000, EXPERIENCE = 2 YEARS , ' ^ 



Ot)viously, the shorthand method is quicker and is the methoa 
used by 'the PlaceireiXt Service staff,"^ ^n either case, the computer 
will reply within seconds with a printed count or total the 
numbet of peVsons on file who are interested in receiving that 
particular job lead — let's say the computer has identified 14 
individuals. 

Nqw there are a number of additional commands which can be ^ 

* ' // 

executed against the group of 14 selected records. The LIST 

command will sim.ply list the names of Tthe 14 individual's. The 

TPRINT cdmm'and will provide a brief printout of each individual 

indicating the" regis trant ' s name, temporary address,, zip code, 

temporary telephone number, .degree date, major field, availability 

date and maiden •name if applicable. The PPRINT command is similar 

except- that it will display the permanent address and telephone 

number. * . • ' ' * 

For the most complete printout, the operator can execute the 

DUMP command which will print for each of the previously 14 

selected records everything on file in a clearly formatted, manner. 

» Please note tliat once the computer has determined those recor^ds ^ 
which meet the criteria of the SELECT or search command, noitc of ^ 
the • subsequent ^comm.ands require a repeat of the search algcrithKt* 
The system retains the computer addresses of the 14 selected 
records which minimizes execution time of other commands. 

The usual objective, of a job <searOh is to have the system 
automatically print the names and addresses of the* selected group. 

jThe PLABELS t command will^f)rint name and permanent 'address data 



in a'proper forroat for th^ 14 individuarls . if the previous search 
had resulted in 84 candidates being selected, then 84 labels would 
print. You can very -easily appreciate the very rearl sayings r^lized 
in^^rsonneL time sintfe manual searching is eliminated— ^so is the 
typing of envelopes, A sample printout of names and"* addresses is 
shown in Figure 2. 

3.2 Other System Uses , All processing of job lead/ do not resul^ 
in a mailing to candidates, Sometimes^a lead is reqeived by tele- 
phone, and the caller wc3<uld like to have the names of likely 
' candidates so that he can personally contact them immediately. 

Under these circumstances, the operator can excuse himself for 

' • ■ 1 

sevveral minytes , go to. the terminal and execute the appreciate •. 
computerized search^along with appropriate printout commands, return 
^to the telephone and provide the caller with as much data as he ^ 
would like on the selected candidates. This is not unusual. • 

Another dommon' occurrence is for a company representative to. 
call in person at the Placement Service office concerning job 
vacancies. , Often he will leave with a computer printout of. likely 
candidates prepared for him while he watched the staff member operate 
the terminal. The only data item he would not reaeive on any DUMl' 
printout would be the minimum salary' that the candidate woutd be 
willing, to accept. For oBvious reasons, the Placement Service does 
ngt want to make this ' information available to prospective employers; 
however,- it is still used during'^the search process to select the 
job candidates. , " ' 



4. ' TERMINAL COMMAKDS ' * I . 

Any terminal language is made up of words ^ which were agreed 
upon with the user during the design stage of the ^project as to 
what they mean and how they will be used.^ ^ 

4.1 The Verbs. These words ai^e used as ' comii>ands to cause the 
— » »* 

computer to execute selected program modules to arrive at desired 
results: 

Short .Version 



Long 



:rsicm 



Function 



SELECT 



Lisa- 
PP-RINT 

TPRINT 

PLABELS 

TLABELS 

DUMP 



\ 



SEL 

Lis" 
PPR 

TPR 

PLA' 

- " ^ 

TLA 
DUM 



COUNT 



COU 



Build a file of selected 
individu'als who meet the job 
criteria, ' The nouns are also- 
used with this verb to fully 
describe th^ job. 

Print only th^ names of thi 



selected individuals 



Print a brief repprt on each 
of the ^selected ^dividu^ls 
usin^g the .permanent address 

Print. aVbrief report on^ 
of the s\^lected indij^^^als 
us^ng th^" tempor^^7 address 

: Print maiii^ labels ^for e^ach 
of the^felected individuals 
using the permanent ^ address 

Print mailing labels for each 
of the' selected individ\ials^ 
using ' the temporary a^l^resfe 

Print a complette record dump 
except acceptable minimum 
salary for each of th^ selectea 
individuals 

Plript the total number of 
'•active records on the Applicant. 
^ Master File . 
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4.2 The Nouns , ^These words are used to define the vacancy criteria 
and are used with the SELECT verb to form a complete commapd state- 



ment »for searchiiV^ th^ files. 
. Long Version Short Version 



, POSITION 
EXPERIENCE 



.P,OS 



EXP 



SALARY 



SAL 



LOCALITY 



LOG 



AVAILABILITY AVA 



DEGREE ' 



NAME 



DEC' 

_ / 
NAM 



Fungtion 

Used to indicarl^. the position or ' 
job code in a search. For 
example: ■ POS •= REG (a regijstr'ar 
vacancy) ■' - 



Used to indicate the minimum 
experi'fence acceptable to the 
employer. For e;xample: EpCP = 5 
(five .years required) 

Used to indicate the sala^ry 
being offered for the- vac^ancy. 
For example: SAL = 12 (candid- 
dates must be willing to/agcept 
$12,000) ^ 

Used to indicate tl\e geographic 
location of the vacancy. For 
example: ' LOG = NEA Coandidates 
must be willing to wOr\ in the 
New England states area] 

Used to indicate when theNjpploy- 
er wants to fill ^he posji 
For example: AVA = IMM {canm- 
dates must be available to b^in 
work immediately) 

Used to indicate' the minimum \ 
educatipnal requirement for the\ 
job. For example: DEG = MAS > 
(candidates must possess at ^ 
least a master's degree) 

Used to search the files by a 
name, either partial or comgle1:e^ 
For example: ^AM = JONES THOMAS^ 
(all candidates with that name 
will be selected) 
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4,3 Search Combinations . By using the SELECT verb and all of the 
nouns (except NAME) to describe the vacancy, the most jcompleta and 
refined search can be made for qualified candidates* Only thpse 
peisons who'tnatch on every criteria will be selected, all others 
excluded, even those who might quaj^ify on five criteria but miss 
out on only^ One criteria will find themselves rejected from the 
selected group. However, it is not necessary to use all^of the 
nouns witji the SELECT verb. The following examples will^illustrate 
the flexibility of the system: 

a. . SELECT POSITION = TEACHING All teaching candidates will 

be selected regardless of the subject area, level hf 
teaching or any other criteria. 

b. SELECT POSITION = TEACHING 4 All teaching candid^tds 
who want employment at a four-year institution ^^wi II 
be selected. 

\ 

c. SELECT POSITION =v TEACHING 4 ENGLISH All teaching ^ 
candidates who desire employment ^t a four-year* 
institution in the subject field of Eng],ish will 

J? be selected. 

You can see th^t as more criteria are added, the search 
becomes, more refined and the selected candidate list more filtered; 
thus, it is possible to really zero in on the most qualif ied^^^^.--^ 
candidates and only inform them ,of the job lead* Tho^^efwio are ' 
not fully qualified by th^ selection criterl^-^-wlTll not be 
botfiered by unnecessary mail 'and/ or course, the prospective 
employer Likewise will not be' unnecessarily bothered. The syst^ir. 
works well for all parties concerned. Just a few more examples 
will illustrate thai: it is not even necessary to use the POSITION 
noun on ^ery search. It all depends ,on what type of information * 



' ... 99 

Vol. II . / 

/ 

- ■/ 

you are seeking from the file. 

d. SELECT SALARY =' 15 All ^andidates^ who are willing . 
to accept a salary* of $15,000 will be selected re- 
gardless of any other criteria. 



e. 



SELECT AVAILABILITY = DECEMBERl All candidates whb 
^are willing to begin, work in December will be selected- 
regardless of any other crii^ria. 



, f. SELECT SALARY =15 AVAILABILITY = DECEMBER All 
candidates who are willing to 'accept $15,000 and 
can begin work in December will be selected. Both 
criteria must be met in order to be -selected. 

•g. SELECT NAME = PET All candidates whose names begin 
* with the letters PET will be ^s^elected — this would 
^ include Peters, Peterson, Petrie, etc. If the 

entire name is known, it can be used to -select ' ^ 
just that individual and others who might have the 
same exact name. ' ^ ' ^^-^ 

4.4 candidate Status . When a person accepts a position, he is 

requested^ to notify the Placement Service so that his computer 

record can be updated to an inactive status. The position he has 

aqcepted is not entered into the files. Only an inactive flag is 

set to exclude the person' from any, future searches thus reducing 

proces'sing and mailing costs. Unfortunately, there is no\way to . 

"eniorce the request, and it is feLt that a number 6f^ successful 

job applicants never do 'notify the Placement Service of their good 

^fortune. The problem is somewhat minimized by terminating the use 
of the old file in September and starting- a new file each Octobor. 

• A person must re-register to g^t back into the system--n(/ rccf.ro:; 
-are carried forward. . . ' . 

5. IN CONCLUSION 

' 'as I indicated in my opening remarks, our Placement Service 
office has had a very good expedience with the . computerized 
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placement system'. Job leads can be process^ swiftly and 
accurately thus providing a very valuable service to our students 
and alumni r,^' The system is easy to modify so that each summer 
prior to^the start of a new processing' year , we wi 3(1 ' implement 
reasonable changes to the. computer system to further enhance 
the effectiveness of the service for the coming year. 

Yes, we do firmly believe based on our experience that the 
SUNYA PLACEMENT SYSTEM is an INNOVATIVE SYSTEM which is a 
SOLUTION and not .an ILLUSION.^ 
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I 'oasis - AN ADMINISTRATIVE DATA I-IANAGEMENT SYSTEM' 

Cheryl M. Travdr^ Associate Director of Operations / ^ 
Georgia State. University, School of Business Administration ^ . 
• University Plaza, Atlanta; Georgia 30303 

In thj^ last five years two ^ajor advances have been made toward the 
improvement of commercial data processing productivity: the File Management 
Systtem and the Management Information System* The f0rmer'is directed at 
'reducing the ,e"f fort in processing volume data, the latter at providing more , 

flexible and timely information out of stored data. Both of these substantial 

, - H . 

needs are prevalent in most commercial environments. Unfortunately, the two 

.types^ pf system are notjftially mutually exclusive as designed and sup.ported. 

Thus, the data processor must select one or'^^^he other or constantly transpose ♦ 

** » • 

his datd between two conflicting data structures* It should be possible tb ' 
. provide a system. that combines the advantages of the Tile Management and Manage- 
ment Information Systems. OASIS^ an Online Administrative Information System 
developed at Stajiford' Universit'y, is such a system. \ ^ _ 

1. ,THE CURRENT AVAILABILITY 

In -the last five years the commercial data processing industry has made ^ 



several attempts toJr^ve. out of the strictly batch-oriented*mode of operation 
which the media of the card and the magnetic tape fiad' produced. Broadly 
speaking, the two mo5t notable changes, were pi;'oduced by the introduction of, 
first the File Management System and then the Managemetlt Information System, 
Thg two systems have basically diffei))ent; goals and, consequently, differ in 

V \ » 

their. characteristics. 

1.1 \rhe File Management System , The File Management System (FMS)* was 
designed! to be basically batch-orlentfed . ^ This does .'not mean that it will^not 
operate via terminals; however, the design was definitely oriented toward 
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*rt\RK IV of Informatics^ Inc*, is a filie example of |the hTIS, WORK TEN of 
^ Honeywell Information Systems is another example. 

' -'.«.. . . 



processing ^ lar^e proportion of the data in an entire data set or ile. 
Traditional 'batch retrievafl methods are^ usually employed.} the file struc- 

1 . " ■ ■• , • ' - 

tures are sequential or employ one major index or key via which the data can 
be retrieved. The rules on subsetting or sorting the dataware in general 
very strict, the only flexibility being afforded yx^ standard system sorts p 



embedded sort verbs. The transaction/master; f ile'^concept^'characterizes these 

systems. They are ^extremely record-oriented and basically designed to access 

each record in a data s^t once (or ve^y few times): to retrieve and/or update 

all of the data yitRin ,a record .iii' a single pass. Consequently, access times 

are primarily dependent on the speed of accessing the device ^and are largely 

' independent of the relative efficiency of *the cpde which manipula^s the^lZ-O- 

.bound routines. ||eavy' emphasUs, is usually placed on the. size of the file.' The 
* ■ ■ . r • . ^ ' 

'power and flexibility are directed at.- reducing mundane ptogtamriier effort. 

Typically ^uch systems provide foi* automatic performance of standard updating. 

functions; transac^^^^/tn^st^ file logic is incl^uded for matching ^records. 

Capabilities for ^e^erating list reports and doing standard subtotalling are 

'of ten advertis.ed^. ^ The ^y^tems are definitely oriented toward the programmer, 

• . "* 

often employing shortcut laoguages and f ill-in-the-blank methods permit- ^ 
. rap|.d prqxliiction of programs. ^ ^ ' i 

1.2 * The Management In form ation System. The MafiaKem(»nt laform/il ioji Sy^^t<Ml^ 
(MIS)^, on the other hand, is terminal (or retrieval) oriented, designed 
primarily *tq handle random req.u^sts for complex .selections of data. Its ^ 
emphasis on rapid retrieval, required the development of many form^ on nori- 

/ • ' . ^ ' . • ■ 

• standard file structures designed specifically for doirfg random retrievals in - 

**TDMS (TS/CPMS) of System Development Corporatipn and IM^ of In tfetr national 
Business Machines Corporation are examples of the MIS. * • . 
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.-the minimum amount of time. Instantaneous response for very flexible yelec- 



tion criteria is of pritnary imponm^^^^ Normally the final output encompasses 




' / ^ ,„■■■,■ 

^ * very few records and very littMRffCa. Such systems often tend toward the 

ftiregrated data base concept: the d^ta are ^arranged within a structure so 
- that ^ingenious intetrelationsh,ips can, be^^produced. Such systems, being 
^ * concerned so specifically with retrieVal speeds, do not place heavy empTiasis 
oji the physical size of thQ files. Iii fact, extra space is normally required 

' ' ' ' ■ V , - 

to repeat data in numerous s.tructures pr to support pointers, chains, and C 
indices to make the rajild location of data easy. These systems are "user 
oriented" in that they provide tools fdr the .user himself to specify and 
produce queries and sip^le iTeports. Sometimes generalized 'facijj^ties ate 



also inpluded Jjfh^ch permit the simple maintenance of data. (Most such.system^ 
do not include convenient progranmier int>erfaces for writing nonstandard ^ & 
programs,) • . / . 

,1.3 The DicliotoiRy . ;Both'the FMS and the MIS provide worthwhile and necessary ' ^ 
capabilities. Th« normal commercial data processing environment has the need 
for prograiriftiihg volume maintenance and retrieval 'functions and for permitting 

^. ■ . . ■ ' - ■ « ■ . / 

the flexible compilation of information from those data. Uilf oxtunately , thos^^ 
-very ^characteristics yhich make the FMS adept at handling. large volumes of 
data restrict the ret^ievaL^ flexibility wherear. the complex file structures 
which allow the MIS fnat flexibility force maintenance functions, to be 

. ^ ' ' 0: ' - 

exceedingly slow., _ • \ 

The c^l-ternative^ for the data pracess'ing ,envirouuifc;ut are noc very |/Lonil.s- 

■ ■ J; ' ■ " - 

;ing. Conceivably, a given installation coUld purchase both types of system 

and U5e each for its »d^igna^ted purposes, j Unfortunately, this would require 

transposing tlfes^ata ^f rom^ne^sy'stem^ to th^ other at frequent^ intervals* » 

" - i-.y-i- 'v/ould be ex{iensive. The Second alternative 



gj^Q Even if this were . possible it 
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* .wouid be to purchase just an FMS, which would roake the programnting burden less'- 
• ■ . ^ . * . ^ \ • / 

cumbersome, but would not ^facilitate the handling of unanticipated' requests. 

♦ The third alternative - to acquire onfl.y an MIS - Is the mo^t accepted today. 

^ . Such a sy*s tern affords* management with the type, of information it wants but-iS 

normally extremely expensive in 'terms of batch 6ompiitin| time for volume main- 
tenance and Retrieval. ' v , ' * 

1.4 ■ The Need ^ It is the conviction of the author that none of these J 

alternatives should be necessary. It should indeed be possibl-e to prpvj.de 6pe 

' ' single system which would combine the advantages of bot?! t^BS of system «i,th 

t ' , \ ' * ^ ' ' # , * 

' none of the large disadvantages thaC each to^ay forces^ ' ^^SucH a system would 

require that the same data base be used effectively for both mass retrieval 

, and maintenance functions and for random inquJLry and terminal updates* The 

batch access and modify speeds must be reasonable; the stoVajge overhead for 

«! — 

online retrieval iiiust not be exorbitant. The system must provide inquiry 
^ c, services and report def in'ition/generati^ features which are directed at the 

• f level of the person who will be the user of ^ these services - i.e^, English- 
* like laitguage in a fairly flexible format/' 

1.5 A Solution. A system that combines the advantages of the File Manage- 
. ^ . ' ^ ^ ^ / " ^ " 

ment Systejn and the Management information System, yet attempts to avoid the 

^ inherent weaknesses of each, is not an unrealistic dr^am. In fact, one such 

system already exists and is operational at Stanford University. Called 
OASIS (Online Administrative Information 'System) , the system was developed by 
Project INFO, a software team ac Stanford University, under a grant from the 
FoxJ Foundation. , >^ 

■ , - • . r- 
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1. THE OASIS APPROACH : ^ ^' ' " . * * 

, . -•:In 1968 the Project INFO team w^s form^^to address the problems of a 
university administrative computing community. Its mission"* was to develop for 
Stanford University the means by which the information ne^ds ^f the administra- 

* V • • ♦ , 

tive environment could be satisfied. (The Requirements of scientific and 

research computing were not addressed..) After a nine-wonth. study, of the 

systems currently available (or nearly available) it wa^ decided that none ^ 

could b^ "-combined or structured in such a manner that the university admini- 

strative needs could ^economically be satisfied^, '^^t that time the basic ideas 

for the design of OASIS were 'formulated. , As the rfame, Online Administrative , 

Information System, implied, OASIS was designed to support both "online" and 

batch activity concerned with normal "administrative information" requirements 

I * 

via an organized and efficient "system". Thus, OASIS' is an attempt to span 

the gap between the File Management System and Managemertt? Information Systetn. 
* ' ^ r ^ 

2.1 The Components , OASIS is highly^modularized to ^i^rovide maximum flexi- 
bility and is ^composed of four Iqgical components: an .Executive Control 
program, -the Terminal Services, the File Servi^fes', and ^the^Generalized Services. 

The Executive Control progra5i performs tradition:al monitoring functions 
to handle the supervision and coordination of the operation of multiple user' 
tasks. The monitor handles, task scheduling and the allocation of memory I/) 
the tasks and tp I/O buff'S'rs. -It also contains a polling routine which 
performs /communications between the CFTT programs and the external user. A 
Command Language* Processor handles simple requests between the user and the 
system. The OASIS Executive- differs frojQ other monitors mainly in the* space 
allocation techniques used by the Linkage Services,* since OASIS Jivide^memory 
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into 2K increment^ in wl?ich the Generalized Services and user tailored services 

^he TermiYial Services provide communications between the user and' the 
system. They afre^ used by the Command Language Processor and the Generalized- 
Services, and are available to tailored applications through standard' high- ^• 
Lev^l language! CALL statements (as, the 'C^OL ^ALL) 

The File Services handle all ^.interactions between the Generalized and 
tai|lo^d services and the OASIS data . base. The structure of that data base 
reflect^the cecognition o-f needs for both unanticipated, unstructured user 
fficient volume rettieval and maintenance. Services are 
:cessing th^ data-in various ways for the varying demands. 

needJ in the 



requests akd 



provided fon a 

• The G^nerkj^ized Services were designe'd to hand^le ^ those 
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administrativele'nvironment which could most readily be put into a generalized | 
format and coulld be utilized by the tiser community, thereby avoidiag laborious I 
programming effbrt. The, Generalized Services consist chiefly of QUERY and the 
Terminal Report! Generator . QUERY ^was designed to handle 'the unanticipated 
user requests. iThe service is available through the terminal and consists of 
free-form Engli*-like sentences input by the user. Automatic editing and 
formatting provitie 'pleasing displays with a minimum amount of user effort. 
The Terminal Repbrt Generator, on the other hand, Was des^igned to avoid some ^ 
of the programming .Jieeded for the fairly standard reports the user sb often 

requires. Repora definitions are Entered through tKe terminal, with a step- 

I . • ^ • 

by-step user guidjsd* procedure, and several options are provided for report 

generation. 

2.2 The File Services . The power of OASIS i^ derived primarily from its 

1 

data management rdutines and its file structure. ' Bas'ed on the assumption that 
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bpth. volume requirements and complex selection crite<ia for low-volume output 

are required,* OA&lS supports both* direcf record retrieval and index-iike 

lookijp capabilitiW. An OASIS data base^is phygicallyK resident on one or 

more /disk storage devices and consists of one or more-v files which m^^ or may j 

not be, related according to tlieir definitions in the OASIS Dictionary. An 
/ X . ' • ^ ' ' 

extehsive set of backup and recovery facilities i$ an integral part 'of the 

; ^ . ' . ' ' ' 

system, / » - ' • ' 

2.2.1 " Record Stru'ctur^ ., An OASIS file is a physical collection of variable 

length' "re'cords". ' All\f the data for a giveiv* record are located in donti- 

guous space^ since it is assumed that the information in that record as soiaer 

how logically related and as sucli will often be accessed together. Eacti record 

may physically subdivided into a sequence of "segments", each of which may 

in turp contain one or more "elements". Logically related elements may pe« 

defined together as a "group". File^ boundaries may be spanned by means of a 

pseudo-element c'ailled an "ii?:tlirect reference". Figure 1 is a pictorial 

desctf.iption of th^ OASIS file strucfufe. 

^ The various segments within 'a rtecord facilitate highly variable length \ 

\ 

' records and at the ^ame time provide a means for efficiently accessing and 

updating logical subdivisions of the record. (Within one file there can be a 
v 

maximum of 25A Affere^it segment types, each Specified as optional, or mandntory 
and Single or recurring.) » ' 

The element, on the other hand, was designed f6r user flexlhfllty nmJ 

\ c 

convenience. Although an integral part- of a record, the c*lement is n<^^ 
dependent on its physical location vithin the record. Associated with e^rh 
element in the OASIS Dictionary are a name and an OASIS ^edit picture which 
determine^the data characteristics and how they are to be edited for display 



purposes** (The rules on edft pictures permit inclusion of almost any print- 
abie chara<;ter») These names and standard formats were designed as a 
V ' con^veniencfe so that data foight be pbtained in a manner more meaningful to the 
layman than* a iiuin&ric or structural description. 
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Figure 1. Oasis File Structure 
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2.2.2 The Services . The File Services routines r'eflect the OASIS record 

structurOf. There are services that deal with data according to' the 'phyaical 

recotd layout: ^ ^ 

GETSEG - Retrieves a particuLaV occurrence (or all o*ccurrences) of one ^ 
segment type in a record, or retrieves an entire record in a I 
' file* ' • / > : 

RPLSEG - Replaces a particular segment occurrence into a data record ♦ - 

ADDSEG - Inserts a new physical segment occurrence into a d^tci recprd. ^ 

DELSEG - Removes a particular segment occurrence, from a data record, of 
an entire record from a file. * 

Other services are iliore ^ser-oriented and less, concerned with the recdrd 

* ' -A ' ♦ * '* * 

format: . ' ' 

■ ' 

GETpATA - Retrieves one occurrence of one or more elements, groups, 
and/or indirect references in a record, or all occurrences 
of one element, 

RPLDATA - Changes the Value of an element in a record. 

GETVAL - Retrieves one^ many, or all values which occur within the 
instances of an indexed element in a file, 

■ / 

These services, used in conjuncti6n with OASIS routines for description and 

I ' . . ■ 

editing, may be used fq'r data indej)endence in a program. In fafct, the 
Generalized Servic^ do employ them in this manner. 

Because of the need for confidentiality where data are so 

readily available, OASIS tjroj^ides a complex security structure. Each file, 

\ 

segment, 'and record \within th^ OASIS data base has associated with it an 

Ml user^s of the system, whether they be t(*rmln/il 
assigned passwords; each of which has .in .kci-s, 
and a modify '"clearance**. All of the OASIS File Services automatically check 
the clearances against the fccjdes of the data which are being requested dnd ^ 
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2.2.3 Security . 



access and a modify "code**. . 
users or batch programs, are 
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perform the service only if J:he security -is^.Valid . Security levels of three 

kinds, are proyided: a main hierarchy consists of 32 security levels (1-32). 

The 2^ fc g xcl u s ive hier,ai^*hi^s> denoted A -thrpugh Z and consisting of levels 1 

through 8, are eqiial in. "security level and normally cover all or part of the 

main hierarchy but do not permit clearance into any .other exclusive hierarchy. 

Absolute clearance is used for satry into all of the* data in a giv^n -file. 

The hierarchies .may be combined in any manwer desired by the user ^ to* produce 
i 

a specific security configuration. * * V . 

2.2.4' Data Base Structure . In' addition to those, aspects of the OASIS file 
structure involving the subdivisions of records, OASIS includes facilities for 
the rap^d retrieval and maintenance of'^hose records.. Associated with each 
file in an' OA^IS^ data base is ar record number index (RNI) . As each new record 
is added to a file, it" is assigned a symbolic r^teord number. The number 
itself !'^G no significance; however, it represe^s the displacement into the 
RNI table where the actual physical location of the' record is stored. When a 
record is relocated during maintenance activity, tt\e change in physical loca- 
tion is recorded in only one place, the RNI. The'signif icanc^e of t;>^ese 
symbolic record pointers becomes apparent when o'ne considers %fie tfii^rd and 
final component of an OASIS file. \ 

A value index table (VIT) may be built fpr each element whose values 
are frequently used in retrieving data. Each VIT t'bntlins an ordered list 
of values existing for that element in the file. Associated with inch 
value is a list of the RNIs of those records containing the p,Trt ir:iilar vnlur-. 

. OASIS automatically updates these VITs during all maintenance Pbftctions to 
the file. . , 
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Figure 2 illustrates the OASIS data base components, 
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2.2.4 Re.tr ieval Methods . The OASIS file structure was designed specificalr- 
ly for several different retrieval methods. The physical layout of th<\dnt.i, 
base itself is also oriented toward these methods. All of the disk spnce is 
divided into 1692-byte blocks, called ''pages", and OASIS reads -in an entlrt- 
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page whenever data from that page are requested ;r-fhe utility of this design* 

characteristic may best be^ observed by examiniag the various retrieval methods. 

^-^ « . ^* 

c ' • V 

The fastest method of accessing OASIS recoir^is^ involves reading the 
records in "RNI order" (the order the records were. added to the file). An RNI 
page is accessed to locate the physical address (page plus displacement onto 
that page) of the desired record and that page i^.ihen read. OASIS will 
average a I/O for every (1670/average-record-le^tB) records (i.e., one I/O 
for every 33 50-byte records, two I ^Os for a 30dO-l5yte record). 

Records may also be retrieved according tc^ tbfe index order of a given 
element or according to a "given value" of such, an element. In this method 
a VIT pa^^ife read to obtain the RHI for the fii^st record containing the first 
value (or the requested value) . Processing theo^^proceeds as for OASIS 
sequential retrieval. 'As in the case of RNI pages^ an actual read of a VIT 
page is not always ^lfe;essary in that^ as many as '548 instances of symbolic 
pointers may be found on one page/ , ' . 

The third and most flexible method ol accessing OASIS records is used to 

4"select records" into a subset of a file or in a given order other than that 
Sf^a single indexed e^jement. This method involves the use of the SELECT 

^^^rvlce. Using as input g^n English-like syntactical arrangement called a 

WHfeRE-clause, SELECT constructs a list of record numbers (and, optionally, 

i / 

accepted segment occurrences) of all records lir the file which meet the 

specified criteria. The specification may contain as many as 20 c^md i Moiitj i 

"* - « 

expressions connected hy OR^ AND, or TAND (a ^jpecial conntr tor permffflnK 

* fc 

comparison of data within a segment occurrence) and up to ten ascending arui/«)r 
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descending sort fields. Pacentheses are supported, and 'opei^ators include EQ, 
NE, GR, LS, LE, GE, and «N (range). 

The power of the facility is derj.ved from the' fact that any' element may 

IS 

be made part of the WHERE-clause. During the pai;se of^t;he selection criteria, 

SELECT first utilizes the indexed ^elements to^form a set of RNIs satisfying the 

criteria specified for the .indexeXjLtems, If necessary, those records are then 

accessed to determine the validity of uniry^xed data. The output of SELECT is 

usually a list of RNIs (which may be saved and reused at a latter time if 

desired). Thus, the entire* record is available for access, without any dupli- 

cate storage space for temporary files, regardless of the elements in the 

selection criteria. It is also possible to perform selectiorPby* q^egment 

ft 

(thus, element) occurrence in such a manner that the caller is returned only 
those segment occurrences within the record that satisfied the selection 



t 



1 

criteria. . , ' 

The various methods of record ^retrieval were obviously designed with 

* ' • H : 

different purposes in mind. The •OASIS sequential and indexed order methods 

\ 

facilitate rapid iianipulation of lar^e quantities of data* The physical 
proximity of all data for a record minimizes th^ time needed to gather all 
data oa a record or to maintaiil large portions of those data at one time. 
Requests for a given value of a particular element are useful in selective 
batch maintenance as well as in online retrieval of records by key. The 
capabilities of SELECT for the complex reordering and subsetting of. d^ta are 
ideal for batch repoi:ting manipulations and for complex online correlations 

V , 4 

of data for management decisions and also permit more simple application 
programming (since conditional selection need not be written *intb each program) 
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2^3l The Generalized Services . Relying heavily on the OASIS File Servlcte^ 
capabilities, the Generaliz^ed Serviced ptovide automatic facil\|.ties by which 
the user may satisfy unanticipated requests immediately and produces countless " 
varieties of reports without costly application programming (and lOng time 
delays)'. Both QUERY and the Terminal Report Generator provide automatic 
editing and make use of the full SELECT capabilities for population selection 
and record ordering,. Full security checking is rendered at all times. In 
addition to displaying elements, groups, and indirect references, facilities ^ 
provide for the calculation of functions (SUM, COUNT, AVG, Mik, and HP^) and 
arithmetic expressions (elements, functions, or literals separated by the^ 
operators. +, ^ 1 . 

QUERY supports both descriptive axid IffiERE-clause requests. Descriptive 
queries permit ^the user •to browse the Dictionary J to review, componentg of a- 
file'tjcr group, values of an element, or names of the files*to which he has' 
access. The more common -WHERE- clause query is used for displaying record ^ 
contents in either vertical or columnar format and may includ| a population 
count. Full paging capabilities as well as hard copy options^ ar^ provided. 
Figures* 3 and 4 show sample WHERE-clause QUERY recjuests. ' 
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first P4ge of QUERY Showmg Infortnabon on Female StudtnU in Several Depertments 

Figure 3 
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1 ■ Figure k 



; The OASIS Terminal Report Generator" (TJIg) was Resigned, as a vehicle' by. 
which the prbg ramming of a large portion of rej/ort-oriented applications might 
be avoided yet was based on the assumption 'that no generalized report defini- 
tion vehicle could provide for every complicated fJi^ of .report In an efficient 
and uSer-oriented manner . Report definition: is accomplished in an interactive 
mode with the user answering such terminal-prompted questions as desired report 
name anj^ output mod^. (Definition may also be performed in batch mode.) 
Automatic page numbering and/or dating may be ^specif led. ' Elements day be f 
designated as control breaks so that total'*and summary functions will be per- 
formed when the valife of ^hy of t^ese elements changes. 

.As the format and cojitent of each line (and associated headings, if 
any) are defined, the user can modify the automatic edit pictures .and inter- 
sperse text. Both data lines (for the detail data of the report) and total 
lines (for. production whenever one of the predefined control breaks change?) 
may be included. • ' • 
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When the definition is coipplete, OASIS'"ge)ierates object code for 



that report and stores it -permanently in ^ spe^a]L file. The user may 

< ^ r V 

then produce the report^or request a proof based on a subset of data. 
The' repqrt may be displayed on the 'terminal ^ith paging capabilities 
similar to those used in QUERY), spooled frorn^ the -terminal onto the 4 
OASIS log tape fo^ later production In batch mode, or' initiated directly 
from the batch partition. 

2". 4 Tailored Services . . Although QUERY and TRG were designed to ^ 
eliminate many of the programming" needs in an administrative en^ronment, 
it was felt that for* the m^y routine functions ^hat would initiated 
coujcitless nuiSbers of time© per day at a terminal, the user should be 
required to enter the minimum of data nfec^ssary to obtain his .required 
output '-'in a fashion similar to pulling ^a tab card out bf a manual file.. 
Tq, facilitate the creation of siwjh tailored services (called networks), 
OASIS includes .support f8r high-level language communicjation with the 
PASIS File Servixies and Terminal Services. To make the programming 
process more convenient, online debugging facilities permit the programmer 
to ,trace, execution, to show registers or^elected portions of memory, and 
to mo'dify' (patch) register* contents and Select ed memory locations. 

The File Servicfes 'routines arc ^Iso available to. batch programs 
written "'in Assembler language or any high-level language which>^upports ^ 
a standard^CALL statement. Such programs, may be writtetV in any style 
natural, to the programmer and may utilize non-»-OASIS files an^^eripherals. 
2.5 Summary . OAS I Se could be called a aompronvtse system. It was not 
designed to* te all things for all environments* and therefore has avoided 
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the inefficiencies of, generality. On t^ '|3tber hand, it was not designed 
with such a specific environment' in loind that its flexibility and diversity 



would be severely, limited, OASIS, ^an_at|:empt to relieve the "programmer 
of some of his burden, to provide the "useir" with flexible means of 
interacting with his data, and to provide 'fm^agement" with a system, 
which can answer its needs and yet not overtax its computing resources 
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, • , ' ^ THE DARTMOUTH OSCAR SVSTEM 

John S, McG^^clue,* Director 

^ * Dartmouth College /Data Processing Center * • 

. ^ ^ Hanover, New H^mpsljixet^ 03755 

•%e Dartmouth OSCAR (On-line Student Courise Assignment and Registration) 

it ' * * 

system provides the Office of the Registrar with an on-line capability for 
assigrilng students to courses, updating course .offerings and distributing 
students kmohg course sections. This paper describes the use^of OSCAR 
during the course assignment process for. a typical term, a brief overview 
of the OSCAR system and the procedui;:^s for changing student course selectio^is 
and ^'updating course offerings, ^ ^ . 

1 > INTRODUCTION x ' ' 

. ' ' ' . : 

The OSCAR sy&Leui operates on the Dartmotith Time-Sharing System (DTSS) 
[Ref, 1,2,3 ] and is accessed through tericihals^ located in the Registrar's . 
Office, During the busiest periods of each cfuarter> t\ie Registrar and his, 
staff typically use about five terminals; DTSS normally supports about 150. 
Approximately 3850 of Dartmouth 's 5400 sjtudents are actively involved 
in the course assigntnent and' changing proctob each quarter, and the 
normal academic load is threre courses per stuidLent. 

The predecessor to the OSCAR system required a great ueai of manual 
^ work- As the number of course offerings increased, 4s students began ^ 
shuttling back and forth between on-campus and off-campus programs, and as 
the restrictions 6n course changes became less stringent,, the manual and 
punched card system began to show signs bf severe stress. In ^response to 
these pressures the OSCAR system was developed during the winter of 1972. 
Both systems ran' in. parallel during the spring, and the OSCAR system was 
put into full^operation during the summer (the lightest term of the year). 
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The following sections describe (i) OSCAR' s use durfng the coyrse 
Assignment process for a typical term, (ii) an introduction to the OSCAR 
, system; (iii) student course selection" changes; (iv) course offering changes; 
and (v) miscellaneous- features of the OSCAk system. 

I 

2. • CHRONOLOGY OF REGISTRATION EVENTS 

Several' months prior to the start of a' new term, course selection cards 
(called "elective" c^rds) .are sent to students. "At the same Vime, an on- 
line file of tentative course offerings is created. This file contains an ; / • 
entry for each-course, but does not include course sections «r laboratory 

i 

periods. Special restrictions required by a department are included/ however.: 
For example; certain courses are open only to (ipperClassmen,, others have ar^ 
enrollment limit, or require instructor permission, etc. When the •Lectivp 
.cards are returned by the students (usually about six weeks before the start 
of the term), they are fed into the OSCAR system and used" to develop a pre- 'I 

• * > • ^ 

lirknary assignment of students to courses. Restrictions and permission are 
automatically checked by the system at this time.-" " , : 

Following the preliminary course assignments," enrollment summaries are 
sent CO each academic department. The departments use these summaries to^ 
<letermine a) the number of sections' required for each course, including 
• laboratory and discussion periods if appropriate,^b) the times at which the - 
various sections will be offered, and c) th? section instructors\. For 
example, a Freshman- English course might have as many as twenty ^ectionsj an 
elementary chemistry course might require anywhere from two »to ten laboratory 
periods. 

.128 
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The data received from the academic departments are used create a 
new OSCAR course data base, , containing courses, sections, laboratory and 
discussion group periods together with the corresponding instructors^ and 
time periods • 

A revised assignment of students to courses is now done using the 
new course data base. This process, is called sectioning and attempts to 
assign students to courses and sections in such a way as to' avoid student 
time c<?r)flictb and keep a balanced euLoLlment among the various sections for 
each course. Avoidance o£ time conflicts takes* precedence over balanced 
enrollment. In case of an unresolvable conflict, a list is printed shoving 
the student^s name, his requested^ courses, the particular courses, sections 
and times available, and the reason fo¥ the conflict. The Registrar 's of f ice 
later examines this list and takes appropriate action on each individual case. 
While the algotithm used is relatively simple - for example, no Attempt is 
made to automatically reshuffle previously determined course assignments - 
it is an enormous improvement over the previous manual methods. At the 
completion of this process class lists for each course are mailed to the 
app^^^iate instructors. 

After registration, there is a five to ten day grace period during which 
students may switch courcSes. When a s;tudettt requests a course change, a st^ff 
member of the Registrar's office, sitting at a terminal, enters the student 
id^ntylf ication number, withdraws him or her from the course to be dropped, 
and sfiecifies the new course requested* If the desired course requires spetiai ^ 
permissions, the system will ask the tefrminal operator if the student has the 
required ^fithor ization* If "the course has sections, the system will attempt 

\ 

■ * 
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to Utilize the section with the lowest enrollment and which does not Haye a 
tline-'Co'nflict with- the student^s other- courses* If the course has required 
laboratory or discussion periods, the student will be placed in one of them, 
using a procedure similar to that used for course sections. At the 
completion of the process, OSCAR notifies the operator of the particular 
assignment made, and the- student is provided with immediate feedback concern- 
ing the success of his request. During the first few days of the term; a6 
many as five terminals may be conneclfed to the' course changing program, which 
continuously updates the course data base. At the end of each day, a list of 
"add/drvp" notices are prepared for each course and mailed to the respective 
instructors. These lists identify students whcf have been dropped from or 
added to each course, thus permitting the instructor to maintain an up-to- 
date cdurse enrollment list. ^ ^ ' ^ 

3. T HE OSCAR SYSTEM - • 

The most important programs in the OS€AR system are: 

CHANGE Used to update student co^frse assignments; 

SECTION Used once per term to do sectl^ing; 

UPDATE Used to add new courses or^^nake major irevis'ions in 

student data. 

In addition, there are a number of initialization and report generation 
programs which are not worth describing here. _ • 
3,1 Accessing CHANGE . CHANGE is a "multiple- terminal" program [4l which 
can be used by several people simultaneously. ^ The first person to begin a 
session with CHANGE is known as the "master" user, and muse select a one\ to 
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eight-letter "keyword" (e.g., brownfo'X, syzygy,' or whatever^. This user then 

signs on to the time-sharing syst;en. under the user number corresponding to 

the desired term (there, is a separate user number for ^ch of tbe-Fall, j 

Winter, Spring and Summer terms). The master, user then" typ4s . - 
' . ■ ■ - * 

OLD REGLIB***: CHANGE 

After the computer responds "READY", the master user types , . ^ 

^ ■ ■ 

LINK keyword, * , " ' 

to initiate the "conference" and to indicate that any nun*er of additional 
terminals (up to a maximum of ' nine) may join the conference at any time. - 
.Users on other •terminal&_may do thi^ by simply typing 

JOIN kejrword ■ ' 

where the keyword used In the JOIN, command rausE be ,tbfe-..same as the one us^d 
' in the LINK command. There is nothing special about the "mast^" user; it 
is simply that one person must initiate the conference, by calling up theT 
program and typing the LINK command, and he is called .^the master, usrer. The 
joiners may be signed "in under any user number and do not liave to type OLD 

before typing JOIN.. . ^- 

After a user has entered the conference (either by initiating it or 
joining' it), the CHANG^ program will type" the message 

ENTER INITIALS, PASSWORD? ^ 
to which the terminal operator responds with his or her initials and ^the 
appropriate password, ' .... 

■ The password provides authorization: it would be undesirable to permit 
students' to juggle their own, and perhaps their unwitting classmates' (?) 
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course schedules. /"Ifhe date, time and opei;ator's initials are written to an 
' audit trail file; which also records fevery studentrrelated transaction for 
later use by various reporting programs. ' , -^^ 

A»brief * stinnnary of the more important commands available in CHANGE- is 
provided below: • ' . ' ' 



ADD 
DROP 
LIST 
FEE 

• 

^CLIST 
STATUS 



Add a student to a course 

brop a student from a course 

List a student's courses > 

Charge a student a fee 

Print a class list at the terminal. 

1*rint the-status of a course (enrollment, etc.) 



Terminate a session with CHANGE 

Find student^s id. number given his last name 

PASSWORD Change initials and password level 

WHO Provide a list of the other conference participants 




EXIT 
FIND 



3^2 The SECTION program . The SECTION program ife used for pre-registration 
sectioning of the entire student body. It is similar to CHANGS, but has a 
more restricted command list, may be used by only one termitial aty time, 
and accepts commands from a file (as weltl ,as from the terminal). SECTION is 
accessed in the same manner as any other program on DTSS: the terminal 



operator types "OLD REGLIB***: SECTION"; when the system answers "REA5)Y"; the 



perator types "RUN" '[51. The principal commands are! ' 



ADD Add a student to a course 

DROP Drop a student from a course 

EXIT Terminate the SECTION program 

SECTION Specify the name of the file of commands 



^3.3' The UPDATE program . The UPDATE program is used primarily to offer 
^ ■ additional courise's or change the parameters on existing courses. The 
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primary commands are: ^ 

ALTER Alter the parameters of a course 

.OFFER Add a new course to the term's offerings 

WITHDRAW Delete a course from the current term's offering - 

REASSIGN Generate a file of ADD commands for SECTION 

• EXIT Terminate the UPDATE program 

STATUS Frint the status of a course (enrollment, etc.) 



3.4 Passwords. When an OSCAR program requests a password the user may enter 
one of three passwords. The first password grants access to conmands that 
enable tohe user to examine student course assignments^ but not to change them 
(CLIST, EXIT, LIST, STATUS, WHO). The. second password grants access tQ 
commands that enable the user both to examine and update student course 
assignments (ADD, DROP, FEE, REASSIGN, SECTION). The third password grants 
access to all of the commands available in^^y one program, including the 
ability to alter the fundamental parameters of a course and to make available 
new courses (ALTER, OFFER, WITHDRAW). Thus personnel outside the Registrar's 
office (e.g., in the Dean's office) may bp given permission to list a 

student's courses but not lo change them. 

/ 

4. CHANGING STUDENT COURSE ASSIGNMENTS 

The primary vehicle for changing student course assignments is the CHANGE 
program, although the SECTION program if also used for this purpose during 
sectioning. The- ADD command, which assigns a student to a course, is the 
most complex and is therefore described in considerable detail. Brief 
descriptions are pTOvided for the other commands. The PASSWORD* and WHO commands 
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are omitted. Appendix A contains an example of a dialog with the CHANGE 
program. • 

4,1 The ADI) command . The ADD command wil^ enroll a student in a course and 
^update its enrollment count. If a course is sectioned, the student will be 
placed in the section with tl^e smelliest enrollment which does not have a 
time conflict with his other courses. If a course has laborajiory or discussion 
groups, the student will be placed in th^ smallest of these which does not have 
a .time conflict with his other courses. | 

.To specify a particular course section, laboratory or discussion group 
the course name may be followed by the^letters S, L, or D and the number of 
the desired section, as in "ENGL 5 S 1" tn: ''CHEM 51 L. 2" (spaces are not ^ 
significant). Some examples are shown b^^ow: 
ADD 107235, ENVS 35, ART 2, ENGL 5 

ADD REL 46, PSYC 1 r. 
ADD PHIL 1 S3 ' ^ (specify section 3) 

ADD BIOL 4> LI (specify l^b section 1) ' 

ADD GOVT 5. 06 (specify discussion section 6) 

ADD GOVT 5, GOVT 5D6 (enroll student in GOVT 5, and 

also In discussion section 6) 

Note tHat section may be abbreviated ''SEC" or "S" laboratory may be ' 

y 

abbreviated as "LAB" or "L" and discussion group may be abbreivated as "DIS" 
or "D". The student id, number may be omitt^ if a previous command (ADD, 
DROP, LIST, FIND) referred to the same student. 

The pr^ram.has a number of built~ir> checka for courses- with enrollment 
limits, permission requirements, and so on: 
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4,1.1 Course closed 

If a course is closed, the message 

course name IS CLOSED 
DO YOU WISH TO ENROLl STUDENT ANYWAY (YES OR NO) ?• 

will be printed at th*^ termiudl. If the answer is YES, the 
student will be enrolled in the specified course. If NO, the 
student will not be enrolled in the course. 

. 4 . 1 .^2 Course full 

If a course is full, the message . 

course name IS FULL 

DO YOU WISH TO EKROLL STUDENT ANYWAY {tfS OR NO)? 

will be printed at the terminal. Far this and ail other ques^ons, 
the operator may answer YES or NO as in 4^1.1 above. 

4 ^1 . 3 Course requires special permissiori 

Jf a course requires a special permission, the message 

CHECK SPECIAL PERMISSION LIST FOR THIS COURSE 
DOES student name HAVE IT (YES OR .NO)? 

will be printed at the terminal. ' 

H.l.U Course closed to freshmen 



If a course is closed to freshmen, the message 

course name IS CLOSED TO FRESHMEN 
*D0 YOU WISH TO ENROLL STUDENT ANYWAY (YES OR NO)? 

will^jbe printed at the terminal* 



4.1.5 Course closed to upper-classmen 

16 -a course is closed, to upper-classmen, the message 

course name IS CLOSED TO UPPER-CLASSMEN 

DO YOU WISH TO ENROLL STUDENT ANYWAY (YES OR HO)? 

♦ will be printed at the terminal. 
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4,1»6' Course open only to seniors • ' • 

If a course is open only to seniors, the message 
course name IS OPEN ONLY JO SENIORS 

DO YOU WISH TO ENROLL STUDENT ANYWAY (YES OR NO)? ■ , r 

will be printed at the terminai. ' ^ ^ 

4.1.7 Course requires instructor permission 

If a course reqUireis instructor permission^ the message 

course name NEEDS INSTRUCTOR PERMISSION . . 
DOES student name HAVE IT (YES OR «0>? 

will be printed at the terminal, . 

4.1.8 Time conflicts ' _ , 

If a time conflict is found between student's current course's and 
the one to which the operator is attempting to add him, the • 
following messages wil be printed: , • 

STUDENT student name IS ENROLLED- IN ^ 
(••• list of student's courses...) 

THBSE IS A TIME CONFLICT BETWEEN STUDENX'S CURRENT COURSES'.AND 
(... course with time conflict...) 

DO YOU WANT TO ENROLL STUDENT ANYWAY (YES OR NO) ? - •,. 



If the operator answers YES, the student will be enrolled in the 
course even though it has' a time conflict with^his other courses. 



The ADD command will accept a series of trailing" letters as part of the 
course specifier to indicate that a student already has, permission for a course. 
The legal trailing letters are listed below: • , ^ 

"C" indicates that student is to be enrolled in tiourse even though it . 
may be full or Closed 

"P" indicates that student is to be enrolled in course even though it 
■ may require permissions or be closed to the student's class (e.g., 
a freshman taking a course open only to upperclassmen) . 



Er|c ■ 13G 



132 



Vol.- II 



, "D" indicates that a student is to be enrolled in the same cours§ twice; 
a "D" will be printed to the left of a stiidentj-s dual enrollment 
courses whan these are displayed using the lifet command, 

"X" indicates that student is to be enrolled in* course even though it 
I ^ may require special permissions, 

' Examples: • * 

ENGL 5 SEC 20 P (override course permissi(5n requirement) \ 
ART 2C (override closed course) 

ANTH 60 CP (override both permission and full course) 

4*2 The DROP command > The DROP command will delete. a student from a course. 

provided that he is currently enrolled in it. The student will also be* 

dropped from the ^^ssociated laboratory or discussion group, if the course 

has one. Some examples are given below: 

DROP 175035, .MATH 13 ^ ^ ' ' * 

DROP 4520, ANTH 1, PHYS 13, MATH 6 

DROP ART 21 (use current student idno) 

DROP BIOL 17 L2 (drop laboratory section 2 only ) 

DROP GOVT 4A DIS 3 (drop discussion^group 3 only) 

4.3^ The LIST command . The LIST command displays the specified student's 

assigned courses in X\;\e f ollowing f orm,at : 

StyDENT yl^o Aaide class: ' 

couf^e . time s^ciai indications (if any) * " 



with one line of output for each c5otrp«e. An. exampie of the command is 

"LIST 40000W", which would show the- course b^ng taken by student AOOOOW, 

4.4 The FEE command . The FEE comma^ accepts a dollar amount to b^ charged 

to the current student (ot course changes. A billing record will be 

appended to the audit trail file for later processing. The FEE Command 

ft 
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must have b^en immediately preceded by^ an ADfi or DROP command which 
resulted. in a course change, . . * 

There is no way .to "revei&G changes through the system^ If a fee is 



erroneously applied to a student, a manual correction mjgist be^ issued to 



the Compt-r oiler 's ,off ice. , . . 

' . / ' ' " ' . ' , * . ' ' . J 

. ^n^e/^CLftT <^commanjd . Th^ CLIST cpmmand generates , a lis^: of all the 

students etirolled"* ih the specified course, laboratory or discussion gr6up« 

Identification number, full name and class are printed for each student. 

The programj«7ill pause after listing every 15 students and the' message 

CONTD^UE (YES OR NO)? , . , ^ * • 

will be printed. If the operator' answers Na, the class list will be ^ 

. ' ^ ' ^ , : * * ^: 

terminated-; otherwise the next group of 15 students will be listed. 
Examples^re: ' - 

CLlST BIOL 4 

CLIST PHYS 13 ^6 ' ' .- 

■ CLIST CHEM 57 . • / ' \ . . 

4.6 " The STATUS command . The STATUS command #i,splays the time, enrollment, 

limits and permission status df ja coursfe. . If the course' has sections, 

■f • ^ 

labs or discussion groups, this information will be displayed for' all 
the sections, labg, etc. It is also possible to request the status of 
,a particular lab ar discussion group. For sectioned courses^the total ^ 
course enrollment will^be printed on the first linfe. An example is 
shown below: ' , * . * 

COMflAND? STATUS AKt.lS ^ • ^ ^ ' *^ , • 

ART ' /"IS . ' TOTAL: 31 - / . ^ 

ART ^15 SEC* 1 P 14 11/21/74 MTH 13i00 - .16:00 MHl 

ART 15 SEC 2 P » *A* 3:7 11/21/74 «TH -13:00 - 16.:00 MHl 
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In the preceding example, the iteips following the course and^section 
number on the last line are interpreted as follows: 

Item ^ Interpretation 
P ^ . section requires .permission 
*** section has no enrollment! limii^. ' * 



17 section currently has J.7 students 

> 

MTH etc, section meets Monday and Thursday from 1 to 4, 



MHl ' the Registrar's coded abbreviation for tlfl|te>ecifiad 

time period 



A. 7 The EXIT com mand. TH> EXIT command terniinates a session witn a course 



enrollment system program. 

FIND command . The FIND cofoms^nd att^ni^ts ta^locatfe th^ specified , 

sludent's identification number for use in subsequent ADD,rDROP or LIST 

command^^SThe output from this command will degend on wh^ether or not the 

program, was able to uniquely identify the student's name. 

4.8.1 If the system was ablej to locate and identify the specified 

student^-^ the message > * > 

^ « • 

student;^' idno name class FOUND * 

will be printed. The student's idno becomes the "current" 
idno and will be used ^ subsequent ADD^ OROP or LISX commands 
until the terminal operator 'specifies a nfew student identification 
number. 



4.8V^.. If the system was not able to uniquely identify the specified 
> stud6n^t, a list of names will be printed: 
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idno name - class, 
name class' 



idno * name • ' class 



;followed by the message 



S6 



ENTER STUDENT IDNO 'OR 'CANCELV? 

Foi example: * . • , ' 

. • ' • • 

COMMAND? TIND BUSCH , . ' 

■* ♦ * ' ' 

POSSIBLE MATCHES AGAJTlST BUSCH ARE:: \ ' - 

120307 BUSCH ANDREA ' W ^ ^ 

•'120896 BUSCH MARGARET R . 7-6 

^» . , , • . ' • . 

'4 ' ' . ' ' - • 

ENTER STUDENT IDNO'.OR 'CANCEL^? CANCEL . 

(The names are real bu£ the id. humbers are~^alse). 



5J uTDATI^G COURSE OFFERINGS ' ^ , • ' , .. ^ ^ 

Exist ingVburses may be altered, nev) courses added or old ones withdrawn 
using the UEDATE program. All course alteration commands require a l^igher 
'password level than student course: assignment commands, ' • 

• 5,1 The .ALTER command . The ALTER command provides the ability to change 
the. division, ln«t:ructor, enrollment limit> t>e^issions, - time and title of 
a course. Although it is also possible to modify the enrollment, there 
should never be a need to do this a^ tb^ enrollmept total is autotlaatically'^ 
updated when students are added to or dropped frpm a course.- The elements 
of a course are called fields , and each field is denoted by a three-letter 

• abbreviation as follows: . •' 
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UJl V » 


uivxsion couc 


* 


enrollfhent 


INS 


^instructor number 
* ♦ 


LIM ^ 


enrollment limit 


PER 


.permission? 


TIM 


time code 


TTL 


. course title 



5.1^.1 DIV-: the division cod^ is a number between O-'and 9' and 
indicates type of divisional credit to be received by a 
student taking the course, 

5. 1.2 ENR> LIM: these fields accept a three-digit number giving 
the new limit or the new enrollment count. 

5.1.3 INS: the instructor number is currently the Registrar's 
^ ' three-digit identifier, althcTugh provision exists for 

' , eventual^ use of the full employee number. 

^ ^5«1.4 PER: fhe arguments to the permission. field ma^ be one ot 
more of .the following: » ' . * 





(courae' 


is closed) ' « 


llpll 


(course 


requires instxi^pt^r permission) 




(cour$^ has special permission) 


tt<nitt 

r 


^course 


is clbsed to Freshmen) 




(course 


is closed to Upperclassmen) 










©(course* 


is open only . td* Seniors) 



^ * The new permissions replace existing permissions ©n a course. 

0.1.5 TIM: the new' time is specified by one of the standard 

^three-character time codes used by the Registrar's office. 

5.1*6 TTL: the title must be enclosed In quotation marks (") and 

may not exceed 20 characrters, as* in TTL "CONSULT FR REGISTRAR". 
% . * ' ' 



« Only thos^ fields' Specified with .the ALTER command will be updated; 

all other f ieldsXremain the same. 

Examples t \. ' " 

• \^ . ' , • 

ALTER MATH 13, TIM HT3, VeR PFX, TTL "LINEAR ALGEBRA" ' 
ALTER ANTH 6, TIM^ 10, INS 357, LIM 100 

5,2 The OFFER connnand . The OFFER command allows a new course to be added 

to the list of course offerings. The^ format of the coimtiand and its argument 

is exactly the same as that of the ALTER command. 

A time code and title must be specified for a new course, and the 
command will be rejected unless they are provided. (If the instructor 
number- is omitted, the default number 000 will be provided. This will- 
result in the instructor name "THE STAFF" in all course list printouts.) 

If a course has no sections, and a section is added, the new section 
must be numbered 2 or above. The main course will become section 1. 

The rules for new LAB/DIS units is as follows: 

5.2.1 if no .previous LAB/DIS units exist, the new one must be 
numbered 0 or 1; in either case, the system will record 
it as number 0^ y 

5.2.2 if previous L^B/DIS units exist, the new one must be 
numbered 2 or greater; the existing LAB/DIS unit will 
become number 1.- 

Examples: 

OFFER CHEM 57, INg 3A2, TIM 2, PER PC, LIM 50, DIV 3 

OFFER ANTH 6, INS 357, TIM 3, TTL "ELEMENTARY ANTHROPOLOGY" \ 

OFFER CIJEM 57, LAB 0, INS 342, TIM 12 * ' \ 

5^3 The WITHDRAW command s The WITHDRAW command removes a course fiom the 

list of course offerings, provided that no students are currently enrolled 

in it. If there are students enrolled in the course, an error message will 
» ■ 

^be. printed and the WITHDRAW command will not be completed.- 
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If the course has any associated sections, laboratory or 'discussion 
groups, these will also be withdrawn provided that the enrollinent is zero. * 
It* Is ,9,lso possible to withdraw a particular section, laboratory, or 
discussipn group; to do this th^ course name must be followed by; the letters 
S, L or' D and the number of the desired section, as in "GOVT 6 D5^'. 

Examples^ ' , . , ^ ^ - 

WITHDRAW CHEM 57 (withdraw entire course) 

WITHDEIAW BIOL 17 L2 (withdraw laboratory srection 2 only) * 

WITHDRAW GOVT 44 S4 (withdraw section 4 only) 

« 

5.4 The REASSIGN command . The REASSIGN command is intended for use in 

expanding or contracting tr^e number of sections in a course, and generates'' 

a file containing a list of DROP commands for all students in the particular 

course, followed by a list of ADD commands for all students in that course. 

-This file is then used as input to the sectioning program, which redistributes 

the students among the revised number of sections. . 

The format of the output file is: 

DROP ' idno, cour^^p * 
. DROP idno, course 



ADD idno, course 
ADD idno, course 



Example: 

REASSIGN ENGL 5 
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An audit tr^il is kept of^all transactions which affect a student^s 
course enrolXment. In addition, an entry is^^jna^ in the audit trail 
whenever one of the main OSCAR progB^ (tlftj^,/ SECTION, UPDATE) is 
run, and an entry is made whenever a ^sejCJ'^^SK^ses tjie OSCAR system. 
Thus the audit trail shows the progr^D^^ad^^^rtiser ^involved in all 



course changes. Several repotts'^are 'pr(jduced..from the audit trail files: 
(i) a report showing all changes made .by ^aeh student; . (ii) a report - 
showing the^aily changes in the enrollment of each course (used to 



update faculty class lists); and (iii) a report in chronological order 
shoving ^11 course changes made during a given tern. . This latter report 
has been very useful to the Data Processing staff in tracing some, obscure 
program bugs which have been encountered from time to time. 

There are four basic types of records in the audit ^^ail files; ^ 
6.J^ Program entry records . These show the program identification 

(CH for GRANGE, UP for UPDATE, etc.), the date and the time. 
6*2 User entry/exit records . These records are created whenever 
a user enters or departs from an OSCAR' program. These records 

contain the program identification, tfie date, the time, and the 

t , ' 

user identif icatipn (three initials). 
6.3 Course addition/deletion records * These records contain the 

user identification, the date, the time, the student number, a 
list of courses, and an indication of whether the courses were 
added or dropped. ' 

6i4 Fee records . These records contain the user initials, date, ? 

/ / 

time^ student identification number and the dollar v-al^e of the 
fee. 
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( jo-in cronferenoe "RAIN") 



\ 



\ 



\ 



\ 



\ 



TERM: 74F 

EUTER INITIALS, PASSWORD? jsm, i ; (suppTy initials, passwoi'd) 

COMMAI^D? find bsnnh (operator^ error) ^ 

BSUCH NOT FOUND t^-^ ' 

COt-lMAND? find busch _ . ♦ 

POSSIBLE MATCHES AGAINST BUSCH ARE: 



12... 8 "busch ANDREA 
12... 3 BUSCH MARGARET R 



ENTER STUDENT IDNO OR 'CAl^CEL'? 12ri .3 
COMf-iAl^D? list 



75 (alt id. numbers have been 

76 altered for security ) 

(enter eecond id, number) 

diet student's courses; note 
omission of id, number) 



12... 3 BUSCH MARGARET R 76 : 

COLT 42 , MWF 10:00 - 11:05, TH 

PKS 1 MTTHF 9:00 - 9:50, W 

MATH 6 MWF 13:45 - 14:50, W 



12:00 - 12:5Q 10 ^ 

9:00 - 9:50 9 
15:00 - 15:50 2 



COMMAND? add econ 1 , y 

COURSE ECON 1 SEC 4 NEEDS INSTRUCTOR PERMISSIOr/ 

DOES BUSCH MARGARET R 76 HAVE IT (YES OR NO)? no 
*ADD- *NOT* COMPii^Sp. 



\ COMMAND? status econ 1 

EtON 
ECbN 



ECON 
ECON 
ECON 
ECON 

COMMAND? 



1 






TOTAL : 


215 












1 


SEC 


1 


P 45 


43 10/23/74 


















MWF 


10^ - 11:05, 


TH 


12: 


.00 - 12: 


50 


10 


1 


SEC 


2 


P 45 


(JplO/02/74 












SEC 




MWF 


12730 - 13:35, 


W 


16: 


00 - 16: 


50 


12 


1 


3 


P 45 


49 10/07/74 












SEC 




MTTHF 


9j00 - 9:50, 


W 


9: 


00 - 9: 


50 


9 


1 


4 


P 45 


' (40)10/25/74 










SEC 




fWF 


ims - 12:20, 


T 


12: 


00 12: 


50 


11 


1 


5 


P . 45 


11/01/74 














mwf' 


1105 - 12:20, 


T 


12: 


00 - 12: 


50 


11 



\ 
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add art 15. 



12 3^ BUSCH MARGARET R * 76 IS ENROLLED IN: 

COLT 42 MWF 10:00 - 11:05, TH 12:00 - I2:5Q 10 

GRS 1 MTTHF 9:00 - 9:50, W 9:00 - 9:50 .9 

■ MATH 6 MWF 13:45 - 14i50, W 15:00 - 15:50 -2 

THERE IS']^ CONFLICT BETWEEN STUDENT'S CURRENT COURSES AND . ■ ' 
ALL AVAILABLE SECTIONS ,0F ART 15 
PLEASE CHOOSE FROM AMONG' THE FOLLOWING : 



* 



ART 15 SEC 1 P *** 14 11/21/74 MTH 13:00 - 16:00 ?"MH1 „. 
ART 15 SECT 2 P *** 17 11/21/74 MTH 13:00 - 16:00 ;MHl 

T t > • 

ENTER DESIRED ■ SECTION/LAB/DISC OR 'NONE'?,^ 

COURSE ART 15 SEC 1 NEEDS INSTRUCTOR PERMISSION 

DOES BUSCH MARGARET R 76 HAVE IT (YES OR NO)? nO 

***ADD *NOT* COMPLETED 

COMMAND? status qrs 1 

GRS 1 • *** (25)12/05/74 

MTTHF 9W0 - 9:50, W 9:00 - 9:50 9 

COMMAND? drop qrs 1 - (drop Greek 3 Roman Studies 

COMMAND? status qrs 1 • 

Qj^S 1 *** (24)12/05/74 (note'drop in enrollment) 

MTTHF 9TC0 - 9:50, W 9:00 - 9:50 ' 9 

COMMAND? list 

12 ...3 BUSCH MARGARET ft 76 : 

COLT 42 ' MWF 10:00 - 11:05, TH 12:00 - 12:50 10* 

MATH 6 MWF 13r45 - 14:50, W. 15:00— 15:50 2 



COMMAND? add qrs 1 (rc^otom aounnr) 

GRS •. i MTTHF 9:00 - 9:50, W v. 9 : 00 - 9:50 9 

COMMAND? **• • * 
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clist art 15 si 



(otass list for ART 25 SEC D 



ART 15 SEC 1 ENROLLMENT AS OF 12/05/74 





m u 




/ D 




A 






23.. 


.0 


DONOVAN MARY E 


76 


40.. 


.'^ 


ALI SHIRIN^ 


77 


40 ;. 


.s 


DELL JAMES R 


77 


40.. 


.w 


FONTAINE ANNE E 


77 


40.. 


.D 


GLICKMAN KENNETH P 


77 


40.. 


.N 


JENNINGS JOHN G III 


77 


r4o . . 


•M 


LANDERS JOHN C 


77 


. 40 .'. 


.Q 


SHEMI BULENT HAMIT 


77 


40 .. 


.U 


TOWNSEND LUCY M 


77. 


63.. 


.6 


MUSTARD MARION M 


76 


83.. 


.7 


STANLEY ALFRED T JR 


76 


85.. 


.8 


SULLIVAN TIMOTHY J 


76 



14 STUDENTS ENROLLED IN ART 15 SEC 1 



COMMAND? list 40...V 



40 . . .V ALI SHIRIN 

ART 15 SEC 1 MTH 

ART 16 , TF 

MATH 13 SEC 2 MWF 



77 

13:00 - 16^00 MHl 
13:45 - 16:4 5^,..,T^;i.,., 
10:^ - 11:0'5, TH 



1-2:00 - 12:50 10 



COMMAND? exit 

YOU ARE NO LONGER CONNECTED TO CONFERENCE "RAIN" 



STOP 
READY 
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VOICE: OUTPUT FOR STUDENT INFDiiMATION INQUIRY 

David T. Clements, Senior Programmer/Analyst 
District Student Information Systems 
Coast Commimity' College District 
[\_ ■ •* Costa Mesa, California 92626 

/ * . ^ * . . . V 

The Coast Community^ College district is currently implementing several 

Synthesized Voice Output applications in both |heir Computer Aided Instruc- 
tion (CAI) and On-line Student Information Systems. This paper focuses 
mainly on the efforts expended in providing a touch-tone/voice-outp\it facility 
for Administrative inquiry of* the Student Information Data Base. The- author's 
intent is to familiarize tjie reader with the components of the facility and 
to propose its employment as an extremely effective mediuif from both cost 
and user points of view. 

i: INTRODUCTION ' 

Man has always regarded his ability to speak as ^n endowment which 
elevates him from all other earthly creatures. Whether he is now ready to 
include the ^'monstrous** digital computer into his eli'te status is debatable* 
But the technology of Audio Response has grown tremendously in the recent 
years and it h^s proven to be, in many applications ranging from Credit 
Inquiry to CAI for the blind [3], an ideal Man/Machine Communicration. 

A recent research article [5] on Voice Response listed. some 18 American 
suppliers of speech generating equipment and systems. The available hardware 
appears to fall into two categories which, for the sake of delineation, might 
be termed Traditional Audio Response and Synthesized Voice Output. The major 
differences between these two types is shown in figure 1. The Traditional 
Audio Response unit contains sophisticated -storage systems which are *'loaded'^ 
with pre-recorded syllables, words, phrases or perhaps full paragraphs. 
Each of these "sound units** is addressable. The host program sends a request 
for a p'articular unit and it is"outpi\t (or more properly, "played")- 

150 



Vol. II 



147 



PROGRAI^ ' 






deterraines 
^6G number ♦ 


« SELECT MSG n 


AUDIO RESPONSE 




traditiomaI 

AUDIO 




pre-recorded - 
words 
phrases 
paragraphs 


/ 0 



Rf-SPONSE 



ANALOG PROCESS 



/fUYING 0F\ 
- UffrSSAGC:: n ) 



ALGORlTH>i , I 



PROGRAM 



looks up 

word 

phonemes 



•PHONEMES OF MSG* 



I 



SYNTHESIZED 
VOICE 



oirrptrr 




VOICE 
SYNTHESIZER 



articulation 



DIGITAL PROCESS 



COiOUNCEDN 
MESSAGE J 



ERLC 



figure 1: Pre-recorded Audio Response versus 

Voice Synthesis , \ ^ 

With the exception of some control uMit logic, ^ tatal analog procedure. , 

A Voic:;^ Synthesizer differs from the Traditional Audio Response systems 
in that there are no pre-stored, pre-recojded sound's, ft reacts only to digital 
excitement.. The host program determines the phonetic structure of its output 
by means ^of a vocabulary lookup procedure or pronunciatioti algorithm and 
sends a binary string of appropriate pronunciation codes to the device for 
articulation/ , ^ 

JVe decided to employ ^a Voice^ Synthesizer* rather than a traditional Audio 
Response system for several reasons. Most notably because it seemed ideal for 

> • ' J . 

_ _ . i 

' TM * 

*The district utilizes a VOTRAX-VI voice synthesizer, supplied by the 
Vocal Interface Division of the Federal Screw Works, Detroit, Michigan.. 
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a wide range of applications. Within our CAI systems, there are many possible 

uses starting with the .study of $peech^ sounds themselves on up to a full voCal 

\ ' " ' r ' 

interface for blind students, similar to the \ipTk in progress at Michigan State 

Univ5i:sity. The Administrative side of th^ house also could visualise several 

applications which shall be summarized later in this paper. . 

-.Another attractive qtfality of Synthesized Voice is that there is no limit 

on vocabulary, size such as exists with those c^^jj^requiring pre-recorded 

units. ^Vocabulary tables may tl^, stored easily/on disk. Our. structure will 

j^commodate iX^^jpare^^ 8000-10000 words with their phonetic codings per 

one 3330 disk cyShinder., Also, an -interactive procedure may be .quickly. 

developed to add ot' refine the vocabulary as. it is being accessed by other 

• •: ^ * ^ ' ■ . '. 

tasks. • ' ' ^ , . r , 

We also considered the'ability to^ dynamically create ^sentejlce^f within , 

the host prdgram a valuable asset/ That is, constant text, mky be spliced.^ 

with vg^riable data to creat| a me^niligful output string. ^ ' ' 

The most convincing argument in favor of Voice Synthesis is i-ts ebctreme 

ecbhomy. Our syntj^esizer may be purchased for approxim'atp^ly $3500:^/ This is 

well under the cost*, of the other Audi-o Response units coihparable to IBNrs.' 

^ ■' c. ^ ^ ■ ■ \ ' ' ■ ' 

,777(^.,iWhichj^rts- at $60,000 and go as high as $230",0d0'".*/c.' 



.*The amounts quptgd are per reference [2], specifically IBM's 7776'^ * 

In all 'fairnesWS^heref a^e .vendprs which appr'bach 7770 compatibility ^ 
*^at a-mor'e faVorabXe^ price. There' are also several vendors supplj^ing devices 
-"''^ith. limited vocabularies for specific application areas a^nd their prices , 

in some cases- are significantly less. To thi^ author's knovl6dge, however, 
V .there i^' currently only one supplier of pure Voice Synthesis Equipment' - / 
(as described in this paperf; the Vocal Interface* Division- of the Federal'' 
ScreSf Works . v " * ^ * ^ P ' * . . , c* 
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2, PRINCIPLES OF VOICE SYNTHESIZER OPERATION AND ITS REQUIRED RESOURCE 

. Phonetic .'(Coding for a Voice Synthesizer is shown in figure* 2, Our 

' ' , . \ 

synthesizer currently reacts to some 60 phonemes, (A phoneme is the siiiallest 

unit of speech.) There are also 'pausing and inflection codes. Note that the 

phonemes and pauses only lisp the low orde^ six^positlons of an eight bit 



configuration. Infle.ction codes 4itili^ze , the h^gh order two bit s'tructure* 



• 


► THERE ^ABE SOME 60 PffoNEMES, 

i 






• PHONEME NAME 


• 

B IN ARY' REPRESENTATION 




AW (as m law) 
^ AH (as in car) 
AY (as. in eight) 
* " ^ AE (as in cat) 
sB (as in. book) 


' - 00111101 
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OOlOdOOl 
00101110 

^ 00001110 




etc.... 
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etc. . . . 






^ PAUSE C05£S» ' ^ 
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> - 
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PAI', (med. pause) 
Pte (long pausg) 


^ *. 00000011 . . - 

' ' •< ooimia. . 
. • • ^anoOoo 
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are.OR*'D into bi^s t and 1 ^ ' 




INFLECTION . 
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1 


^ m (low)' 

0r2 (normal) , 
^ S^-v KJ3".<high) ^ 
<^ * IV\ ihigher) • 


looooood ' " 

' 11000000 
nonnoono ^ .^"^ 

oioooootf-- 

_ r • . .'^ - 




^ exAMI^fE: 'Jhe word HELP is 


cpnstfucted a^-ftfUows- ^,.f * 

* 'fc' ' ^*-''' 




inflection 3 
pho.neine H 


1^1 1 ,1 
eFST DHJ * i L p 




"binary^. OOOllOll 1^^00001- lOlOOOll^UOOllODO 10109101 



'figure 2: Phonetic coding and Its binary representation 

An inflection is properly '4^'d to a phoneme for the desired sound. The example 
shown for .pronouncing the |<ord HELP indicates inflect ion/ phoneme notation 
and the resulting binary codes. The H sound, of course^ must be stressed; 
thus a level 3, high reflection. Note also that two phqpemes are required 



" Q to accomplishs^he diphthong vowel *sound* 
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" ^ Xhe device obviously belongs in a real-time environment. Because it has 
been engineered to interface per the EIA standard RS-232, there are several 



configuration opportunities/ We Tiave supported two different. .connections. 
.Figure 3 depicts, the synthesiser .connected in^rallel vfith a CAI terminal. 
This is accomplished by social strapping, and subsettihg tHe' RS"-232, interface 
[2-]. Wh3t appears on the terminal is also spoken; an ideal coordination 
for trying new words and inflections, i 
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figure 3: Voice synthesizer is parallel with terminal 
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TOUai TONE TELEPHONES 



figure 4:^ Voice s^thesizer with t6uch-tone interface 
pur other configu5at^x)n shown in figure 4 interfaceis the synthesizer to 
a Bell 403LC data set and subsequent acoustical touch-tone interaction.* , 



O „ *Unfortunately only one touch-tone telephone may in-teract mth the configuration 
ER^C at-a time. We are hopeful this limitation will be soon alleviated by an , 
i^msam economic multiplexing opt.ion. 
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3. SOFTWARE PROCEDURES FOR CONTROLLING VOICE SYNTlgSJZERS 



The Coast Community CoHege district supports two teleprocessing systems; 
namely, APL/SV for CAI activities and ENVTRON^/r' for Administrative on-line 
applications •* Speech synthesis* is used in both systems (ref, figure 5) • 
Currently, we develop new vocabulary in an interactive mode under APL/SV, 
The vocahulrary table (Lexico^) is stored iif a ,s^uential file. Of course, 
small vocabularies can also be stored as direct variables in the APL work- 
space. The APL vocabulary table is subsequently read by. a batch PL/1 program 
which hashes the elements 'into a new structure called PHAST (Phonetic Hash Table) 
Administrative on-line applications may then access the vocabulary in $NVIR0N/1 
thru a common. lookup Procedure module. f 
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AWtlNlSTRATIVE 
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figure 5: Host systems and Voice output configurations 



^ **ARL/SV is a proprietary program prp^ia^ obtainable from IBf-l. 
gf^^^" a proprietary j^rogram obtair(abl^/^om CINCOM. Systems, Inc* 



ENVIROSl/1 is 
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It should be noted that this scheme (figure 5) is utilized mainly for its 
^ Convenience. Jt is not necessary to have the 'word-building capability 

singularly in APL/SV. However, the terminal-synthesizer configuration employed, 
by APL makes the effort quite simple. You try a wbrd^ hear it, modify the 
phonemes, and try again. » ' ' 

4 * 

the^PHAST vo^bulary table is structured with a prime hash algorithm, 
Th^s is an expedient organization for the random access imposed by the Lookup 
Procedure. The table is maintained at a load factor below 70^ to enhance 
search performance. Our average search is accommodated by 1.8 probes. And, 
because of the nature of E^A^IRON/l, s^rches for common words are often resolved 
in buffer store. ^ - 



The rather traditional process of the Lookup Procedure is shown in the 
flowchart of firgure"6. -The application program invokes the procedure by means 
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figure 6: Logical flowchart of PHAST Lookup Procedure 
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of a CALL and a text/ sentence string parameter. Scanning determines the 

« 

text elements. If a numeric is detected, it is tested to see if' it is evenly 
divisable by 10 (modulo-lO). If this is the case, the leading digit's 
phonemes are concatenated with the phonemes of its place indication. For 
•instance, the numeric text 700 would be pronounced ''seven" "hundred". 
If an application program desires place indication verbage in its output, 
it purposely uses this logic. For example, if the value 1,234 is sent to 
the Lookup Procedure as 1000 200 30 4, it would be pronounced^as, "one 
thousand" "two hundred" "thirty" ancFthen "four". Numeric text which is 
not modtilo-10 is pronounced digit by digit. 

When a "word" or more properlx a string of contj^guous characters bound 
by separators, is detected, it is used as ,a search argument into the PHAST 
vocabulary. If the searph is successful, the associated function of phonemes 
is output. Otherwise, the word is pronounced, or spelled, character by character. 

Separators are used to issue natural pausing. As you can see (figure 6), 
the presence^of a period effects a long pause, a comma obtains a medium pause, 
and all others such gjs hyphen, colon, blank, et?. result in a short pause. 

Mention should be made at this point about an automatic pronunciation 
algorithm. Bell Laboritories has published actbunts of a program which 
iproduces Synthetic English Speech by Rule [4]. Although the speech' produced 
is not inflected, it is intelligible on at least 97% of running text. 
Implemented on a PDP11/4S, it requires about 15,500 bytes. It contains some 

750 pronunciation rules and requires a lexicon structure for words which are 

' If* • . 

determined to be 'exceptions to the rule. This is a pro!l?ising effort, and we > 

* ' ^ 

believe oyr next prboeduraf step will follow its guidelines closely. 
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4. VOICE SYNTHESIS APPLICATIONS FOR STUDENT INFORMATION SYSTEMS 
4.1 Application Design Considerations » There are several considerations which 
should be included in the (lesign of any application programs which intend to use 
Synthesized Voic^ Output. An anxiety which pops into every Administrator's 
mind is that the "whole world" will be able to listen in to spoken output by 
simply lifting up their telephg^e. Security, therefore, should perhaps be 
considered before anything else. We have two levels of security checking. 
The first .clearance is obtained after the initiajl connection when the User is 
asked "WHAT IS YOUR USER NUMBER?" He must respond with a pre-assigned number 
followed by a password string of digits. If his entry at this point cannot 
be found within our User Security Registration Ifst, the User is asked to 
in^ut tl^e^ number again. If th^^ second attempt^^lso failS;^ we hapg-up jthe , 
connection and write a message to the computer operator indicating that an 
unsuccessful "sign-on" was attempted. 

Assuming a good sign-on, the User is then asked to "ENTER PROGRAM NUMBER". 
He, of course, must kno^ the particular number associated with the application 
program. After this number is entered, the User's Security Registration record 
is reviewed to ascertain whether he is authorized to proceed. 

Two other considerations are Brevity and Clarity. The old expression 
"keep it short and to the point" is an ideal mandate for Voice Output messages. 
It will undoubtedly be the application designer's first inclination to make the. 
voice output as "human-like" and 'natural as possible. But, no one wants to 
hear a long-winded computer^ Abbreviated, precise sentences are very effective, 
especially when the User will hear the sentence everytime he accesses the 
application. Clarity, by the way, is often enhanced with good pausing between 
words. (When in doubt,' throw in a pause.) Further clarity is also obtained by 
setting the Synthesizer's voice pitch to a low bass. 
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The application prAgram modules should always be both intjstruptable aiid 
repeatable. These are /User considerations. If he has heard all of a message 
he needs, he should have the capability of breaking the transmission. We use 
the key on the touch-tone pad for this function. The User may also^wish 
to^hear a message again in the case some interference occurred!\ Although we do 
not have a "repeat** function key, all applications are divided into brief 
data-text modules. Any module can bfe repeated simply by calling for it again. 

Certain limitations should be realized if the touch-tone phone is used 
as a ''terminal*' . All User input can only be numeric. This imposes quite a 
handicap on data-entry. There are schemes, however, where the User indicates 
with one series of digits that th6 n^^c\ series of digits is supposed to be 
^ ^alphabetic and visa-versa,, but^, tbese are cumbersome, to say the least. 

Anticipating the User demand for an application is an important considera- 
tion' because it will hopefully help determine the traffic increase on the 
equipment* Unfortunately, this evaluation will lead the designer into 
telephone queuing theories and their complicated analysis. But, a sure death 
for a new application is the User community's reaction, "yeah, sure it's great, 
if you can ever get past the busy sigjial"* 

• * ' \ 

4.2 Student Information Inquiry . Our first voice output application for 

Administrative Users was designed primarily for some 50 Counselors within 

. the district. The initial draft of the facility was purposely kept simply as 

If . 

we knew the implementation effort would involve a tremendous education in the 

technical support area. The primary function of the application's to quickly 

provide the Counselor with student demographic^ data as well as summary information 

on TiiS current activities. 
« 
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The flowchart in figure 7 depicts the logical construction of the applica- 
tion program and its User 'interface. After passing a resident security 
procedure, control is passed to the application's main modille which immediately 
identifies itself by. outputting ''This is the Student Information Program". A' 
re^ is then issued^ to the User's terminal/telephone after the promptJ.ng word 
"Proceed" is spoken. At this point, the User has several options. If he wishes 
to terminate,, he inputs (keys-in) '999' whereby control will be returned to the 
security procedure and subsequent opportunity to select a different application 
program will be offered to him. The other input options are either a student 
number specification, or an inquiry module code. A student number should be 
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Logical flowchart of Student Information 
Voice Output application program 
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specified first as it is the impetus for the Data Base call and the storing of 
the student's information for subsequent interrogation. A moduje which repeats 
the student's ID number and spells the name is performed at this point to verify 
that the correct student has been accessed. 

Once the student's information is in storage, several brief inquiry modules 
may.4)e requested, in any random order. For instance, if the User responds to 
'Triceed'* with the digit 3 input, an associated module outputs summary informa- 
tion about the student's current activities/status. The text of this module 
is shown in figure 8. Note that variable data is easily concatenated with 
'constant text to form one message string for the Phonetic Lookup Procedure and 
the Synthesizer. . \ 



INQUIRY* MODULE - DIGIT 3 

Spoken if Withdrawn 

"STUDENT IS TOTALLY WITHDRAh"N" 

Spoken if Active ^ 

"STUDENT IS AfTlVELY ENROLLED IN (number) 'UNITS, 
FOR (nuraber) ^XNTACT HOURS. (HH/SHH) 
!S WITHDRAWN FROM (nuaber) UNITS. 
STUDENT IS CLASSIFIEQ AS A (FULL^PART) 
TIME (DAY. EVENING) STUDENT/* 

if applicable 

"(HE/SHE) IS CONCURRENTLY ENROLLED IH HIGH SCHOOL." 
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figure 8: Output messages of inquiry inodule 

- for Student's Current Enrollment ^Status 

We currently have eight various inquiry modules which are requested by 

associated inputs of 1 thru 8. The effects of these modules are summarized in 

figure^. The inquiry module for the digit 2 input perhaps requires clarification. 

Our district is composed of two Colleges. Thre^e semesters are always maintained 

on-line. Hence, there are six different semester data sub-sets. The User must ^ 

specify (via conversational input) which college and semester he vishes to \* 
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reference. Once specified, the reference is stored with the User's security 
registration, and used by all subsequent Data Base calls. The User may change 
the reference at anytime. 



^INQUIRY MODULEjS 
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2. 


USER IS ASKED TO INPUT COLLEGE AND YEAR SEMESTER REFERENCE. ^ 


3. 


STUDENT'S 


CURRENT ENROLLMENT STATUS IS SPOKEN. \ 


^ 4. 


STUDENT'S 


CUMULATIVE CPA DATA IS SPOKEN. 


's. 


STUDENT'S 


MOST RECENT SEMESTER CPA DATA IS SPOKEN. 


6. 


STUDENT'S 


CHARACTERISTICS (SEX, fifiE, MAJOR, ETC.) IS SPOKEN. 


7. 


STUDENT'S 


ADDRESS AND PHONE IS SPOKEN. 




STUDENT'S 
IS SPOKEN 


ACADEMIC STATUS (PROBATION, DEANS LIST, ETC.)* 



figure 9: The various inquiry modules and their 
c input codes 

Upon completion or interruption of any module, control is returned to the 
prompting "Proceed'* ahd a terminal/telephone read. (A module may be' 
interrupted at anytime by depreg5«^lhg the * key.) This affords the User tjie 

-ability to stop sorngthirfg' he does not need to hear, or easily repeat a module 

— " { 

which he could not hear well. 

» 

If the User forgets which input digits relates to the va.:Eious modules, 
he may input^ 1 which will result in a ''Help" message that details a menu of 
the available modules within the application program. We plan to make this 
a standard for all future voice output applications. This is a more expedient 
reference than the User Manual ... (which for some reason can never be found!) 
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4.3 Other Applications > 

As mentioned previously, we are able to visualize several otKer Voice Output 
Applications for our Administrative Users,, as well as a number of extensions to 
the program just described. 

One of our analysts is currently designing Voice Output interface to the 
on-line Budget System. The scope of this application will provide all 
department heads the capability to inquire about their particular budget accounts 
the balances, P.O. status, encumbrancesy, etc. Because the district operates 
under a centralized accounting organization, this facility will expediate the 
often burden^me communication now in effect. 

We are also laying out an application which will output numerous on-the- 
spot enrollment statistics as the On-Une Registration procedure is in progress. 
This will include the 'capability to alter the OPEN or CLOSED status of a section. 

Rather than supply each of our programmers with desk calculators, we are 
implementing a Voice Output Application for simple calculations. This will 
include the decimal, octal, or hexadecimal base specification. 

Tliexe are many other ideas, which hopefully, the reader at this point 
can also visualize. 

5. SUMMARY 



The relative effectiveness of the touch-tone/voioe output facility provided 

for our Administrative Users needs to be evaluated .from two points of view; the 

User's and the Cost. 

The User's appreciation for the facilities far outweighs his criticism. .To 

I begin with, he considers the "talking terminal" a dramatic advarxe in service 

provided by the Information Services department. He relates that he is abl^ to 

-^-r^ react more immediately to voice than to any other means of communication 

q, (Immediacy, by the way, is the real key to proper voice output information 
O 

ERIC processing. [5].) 
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The' User is also pleased that he has a sufficient number of "terminals*'; 

effectively there is one. on every desk, every office. This is to say nothing 

of the fact that he may use his ^ome phone, or any other off -campus, instrument. 

'And, these "terminals" are compact and easy to operate I This is to say nothing 

of their dependability. 

The medium is only effective^ howevei?, for applications which are limited 

in scope. Speech rate is considerably slower than eye-scanning. Therefore, 

..more complex and detailed output is often better communicated in printed form. 

When the User first hears -his talking terminal, he will complain that it 

does not sound right. He is correct; it has an electro-mechanical accent 

which takes a few minutes to become accustomed to. It is possible to achieve 

extremely natural sounding messages ^d sentences us^ng inflections, but it is 

an arduous programming task and does not lend itself to the word by word lookup- 

♦ 

output sequence. The User ^wi 11 quickly adjust anyway. 

The most significant amount of effectiveness is realized'by the cost. If, 
foi?- example, a two synthesized configuration 'is procurred for $8000 and they 
adequately support some 80 Administrative Users, .the net terminal unit cost 
works out to be $100 each.* And, by allowing this volumd of terminals, you are 
really supplying an Information Service. ' - ^ • ^ 

We feli very strongly about the possibilities of Synthesized Voice Output, 
and are amazed at the results we have achieved with it to date. We believe 
it will become -a widely used medium in the near future as more Educational 
institutions learn of its advantages.- To these installations, we of course 
extend our experiences and encouragement. 

' V 

*Touch-tone pad adapters, ranging in price from $60 to $100, are available 
for standard^ telepiiones. 
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The major emphasis during the-^arly stages of the^roject has been the 
development of the FIND system as an easy-to-use .information retrieval tool* v 
The "host language" contajins simple;' yet powerful, commands for data retrieval, 

: ' ' • 

query/ maintenance, and display, ^he command sfHcture of the FIND language 

• * * 

utilizes a number .of .active verbs to describe the type of operation to be per- 

formed on a working data set: RETItlEVE, SELECT, SORT, PRINTS UPDATE, RESTORE, 
etc. These commands are frequently modified by argument lists indicating the 
particular scope a user desires fgr a comm^d (see the attached sample session). 
Although not readily 'obvious from the^ sample, commands may. be performed in*\- 
whatever order necessary to produce, a , desired result. . ' ' ; . 

Not only is the "host language" presented In easily understobd terms, data 
descriptions are also conveyed in^on-technical Ifrnguage^ Data, sets are de- 
picted as collections of attributes , or, characteristics, pert^^ng to entitieg, 
or objects. Entities may be things ranging from employees or students to 
revenue and, expense accounts to office spac6. Attributes may be aky charac-^ 
teristic of entities—these^ attributes aire mnemonically named to provide users 

an easy access mechanism to the pieces of information they require. 

*■ ^ * . 

INTRODUCTION • ' 



Project FIND {Forecasting Institutional Needs at 'Dartmouth) has been es- 
tablished to provide a^means for making institutional dat;a more readily acces- 
sibj^ to the college's officers and to develop models of the institution's 
operation to facilitate long-range planning. To satisfy Jthese goals Project 



FIND has three objectives: ^ 
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(i) to'provide a tooXf requiring minimal coit5>uter expertise, allowing 

administrators and faculty to obtain current information about 
^» institutional data, 

(ii) to provide a un*w?sal .format and language through which members* 
o'f the- college community can manage their private data in conjunc- 
tionowith institutional data, and » . 
* (iii) to provide a planning tool for festimating the effects of changes 
in insti.t\j|tional policy. [1] * • 

.This paper focuses on the first two of these objectives—a computer system, 
also/called FIND, for the management of data. This system is availaljle to any 
member of the college commfmity through terminals connected -to the Dartmouth 
Time-Sharing System. As an institutionally recognized data management system, 
FIND has been operational for about a year. It is widely used by people in the 
offices of Personnel Administration, the President", Student Affairs, the Dean 
of the^FacultyT.the College' Editor, the Budget Officer, Alumni Affairs, Invest- 
mentai^ and Affirmative Actionv . " ^ ■ 



1^ 



. ■ THE FIND SYSTEM^ ' • • 

History .->'•. ; 

" ■ ' * " ^ 

^ ^oiect FIND "Was actually initiated in April, 1972, in a course- taaght by 

President'* Ke^eny.^-'The efforts of that course produced the first version of the 
inforgiatioa retrieval system in a^^ne, 1972. <^ At that tike the Director of Data 
Processing became responsible for the further development of the software and 
the . definition and inclusion of institutional data into 'the system. During the 
next three months, the original programs «?ere r4fined; new ones were added to. 
perform simple statistical analyses'; and^data bases including the college's 

' ' ... " ^■S^- ' - ■ * ■ ' . 
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faculty and administration -were cast-*tsi FIND's data format ♦ 

The 1972-1973 academic year saw the use of these data bases, and others 

with personnel and financial orientations , by the upper levels of ma^ia^ement 

* •* , 

on an ejcperimental basis- Because the original system h^d?only retrieval, 

subsetting, and display capabilities, one of the primary programming teisks 

during this period was the design cind development of a data base maintenance 

system to aissure ,the timelinesa of information contained within the system. 

In the fall of 1973, President Kemeny announced that FIND was to be the 

official repository of the college's institutional, data and that the' initial 

f , * 

thrust would be' in the area of employee personnel refcords. - 

In the past year this initial, basic personnel data has been expanded £o 
irteetthe varied needs of many sectors of the college. Data descriptions have* 
also been standardized to assure uniformity of meaning of common data elements^ 
useS in various offices. New commands haVe .been added to the system as users* 
have indicated the need for increasing flexibility and expanded capabilities. 
In fact, -an interesting side effect of the implementation of the project's 
third objective—forecasting—has alioweci the user corrjmunity to wrii;e proce- 
dures which they -needed for a specific purpose. Some of these User programs 

♦ I* • , 

have universal applicability ^ and ^is tact was ,redognilzed by the FIND staff, 

who modified the programs to beccMne integral parts of the FIND system. ^ . 

» 

The FIND Language 

The FIND language provides its users a flexible, easy-to-use capability 
to access ,^,jn4^fy, reorganize/ and display infoi;majtion in permanent data bases. 
The language has been designed around a number of ^universal utility functions 
whiofi, are applicabl^e to a number of administrative \off ices and provide the user 
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.community with varying degrees of sophistication in their manipulations of a 
working data base., FIND commands m^y be grouped into five broad classifica- 
tions: informative, primary (or elementary), advanced, miscellauieous/ and 
maintenance.* Each of the five general areas will be discussed and reference 

will l^e made to the use of many of the cOTanands in the sample session shown 

* ^ ' i 

in the Appendix, , ^ . . ^ 

Informative commands are designed to prompt the memory of casual users- and 
to provide a short introduction to the novice user. Probably the most informa- 
tive of these commands is EXPLAIN, which provides descriptions (brief l^^^a ted) 
of each valid coiranand and of many additional key words used in reference docu- 
ments. For the user who knows *the general scope 6f his investigation (that is/ 
which data base contains the' de'sired infonaation) but is unsure of nomenclature, 
the ATTRIBUTES command provides a display of each abbreviation available in a 
'particular data base. ' To determine the institutional meaning of any attribute, 
one of two commands may be' issued.- The DESCRIBE command gives a brief explana- ^ 
tion of an attribute and its characteristics; the DETAIL command provide? the 
coihplete.institviti'onal definition and a list of all the possible codings (for 
attributes whose values have been shprtened to reduce the stoij^ge requirements 

of a data base) • ^ * 

The primary commands are of the most in?>ortance to a user, for they provide 
the means of data ac9ess and manipulation. * The first command normally issued 
in a PIKD session is a RETRIEVE, which copies, data from a permanent da^ base ^ • 
(described below) to a working database. ^11 subsequent commands' act upon the 
working data base', allowing a user great flexibility without the cpportiinrty to 
' alter the permanent, or institutional, data base. The other primary commands 
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■i - • 

are SELECT, SOI^, RESTORE, PRINT, and' STATISTICS. Each of these commands 

specifies a type of operation ,to be performed on the workiJi^data base. The 
SELECT command" allows^e u^r to subset the. worKiHg-^iata base by providing a 
logical expression specifying the inclusion criteria for the subset. A working 
data base, or a subset thereof, may be reordered in ascending or descending 
alphabeUcal order according to any single attribute or group of attributes. 
(The sorting algorithm used .treats all values as cha?:acter strings and sorts 
these character strings according to their ASCII values.) Because the SELECT 
command causes the "working data base subset" to shrink, and the SORT command 
'destroys the original order (or non-order) of a working data base, the RESTofe 
command is very important for it returns a working data ba^e to its original 
fo^ "subsequent to . a RETRIEVE command . Simple lists of fentities in the "work- 
ing sulpset" may be requested by 'a PRINT comm^d. The list of attributes may 
be .specified,' in which case they are printed as requested, or no list may be 
' given, and all the. attributes will be printed as they ^re encountered in the 

wo:^ing- data base. Finally, the STATISTICS command provides the standard uni- ^ 
-variatp statistical measures of a numeric attribu/e (mean, median, and range). 
■ Advanced commands give a user the power of more advanc^ statistical 
techniques, the capability to combine attributes arithmetically, or , to format 
^more nicely a printed display. XTAB provides the user with simple frequency . 
• tables foa^one or two attributes; FIT provides linear or exponential curve- 
fitting .techniques- (regression) and CORRELATION provides bivariat^ correla-^ 
tions of .attributes. The DEFINE command allows the user to crfiatje new att;:i- , 
. butes ^ a. function of existing attributes, and constants, using simple 

Basic-like .statements to_ convey the exact-operatioKs' he wisheg performed. ^ 
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Finally, the FCRi-lAT coninand allows control of the format (spacing/ layout, pagi- 

nation, page dimensions) of a printed page, ' * ' ' 

* - » 

Miscellaneous coinmands provide users with amenities not entirely necessary 

to the existence of an information system, but which m^ke life more becirable 
for the user. For example, a session at the terminal might have- to be inter- 
n:5>ted for, some resison before the desired analysis or report is coir5)leted. To 
allow a user to "pick up where he left off," the SAVE and 'LOAD conmands ,^e 
lifesavers. SAVE makes a copy of the working data base <and an^.s\J^>s^t) at a 
particular instant, and LOAD when issued brings that copy back into the FIND 
system as the current. working data baise. Additional commands of this type in- 
clude RENAME, OUTPUT, LABEL, SCRATCH ,^ COUNT , REDUCE, and H^IME. Many of these 
ccOTuands cire self-eyident. RENAME allows the user to change the name of an 
attribute to something more meaningful to him;' OUTPUT provides the capability 
of directing printed output to a file rather th^n the terminal; LABEL allows 
the insertion of textual material at the head or foot of tabular displays. 
The SCRATCH command erases some or all of the attributes from the working data 
base, all<^ing the user to access multiple ^daja bases, in the^same session with 
FIND. QOtJNT gives a user the current number of attributes, entities, and' en- 
titles s.elected in the working data base. REDUCE causes the worki^g data base 
to shrink to the size of the selected subset; this i« most useful in the prepa- 
ration 'of reports and data files. for specific offices of the College. Finally, 

the TIME ^mmand tells the amount of CPV time used since the inception of the 

^ • ' "* 

sessioh, - , , - ' ' 

/ Maintenance commands insure the accuracy of the various data bases. They 
are- the vehicle for adding new entities to a data base, deleting ^nti.tie$ n6 
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longer in a data base (terminated employees discontinued fiscal acqounts, etc.), 
, and the alteration of values for existing enti*ties. A special command, UPDATE, 
signals FIND that the user wishes to be placed in the maintenance system, where 
he may issue the special maintenamce commands: IDENT, LOG, ADD, DROP, ALTER, 
and MODIFY. - IDEOT is the first coipmand issued in the updating scheme, and it 
tells the system which attribute (or attributes) the user wishes to use as 
identification attributes for the balance of the session (or until another 
IDENT command is issued) . Because the UPDATE command and its associated com- 

f 

j^ands alter only the working data base, it is necessary to provide a means for 
conveying information about updates to the permcinent data bases: this is done 
with a LOG coimnand, which specifies the name of a file in which all alterations 
to the working data base are t© be stored* The LOG command causes recording ^f 
subsequent alterations only, ^ny changes in the working data base prior to the 
issuance of a LOG command are not recorded. 

Actual data modification occurs only when the ADD, DROP, ALTER, or MODIFY 
commands are issued. The ADD coircnand adds an entity to the working- data base. 
Upon issuance of the ADD command, only those attributes identifying the entity 
e^e added to the working data base; spaces are left for the subsequent filling 
of additional attributes using the ALTER or MODIFY commancjs. The DROP command 

4 

causes an entity to disappear from the working data base; in its place a vacupus 
entity nppears if the data base is restored/ The ALTER and MODIFY commands 
allow the user to change dat^ in existing records or to insert additional attri- 
butes for Entities recently' added. An ALTER iroirenand specifies a particular 
/value for a single attribute 'to be changed, while a MODIFY command allows a , user 
to enter values for a list of attributes for a single ^ntity. Because Qf this 
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difference in structure, the ALTER coinaand is designed to change the particular 

f 

value immediately; the MODIFY command "stores up" its lists of values to be 

altered until the user specifies that updating should occur. Once an UPDATE 

session is completed and a user wishes to return to the inforrnation retrieval 

t . ^ 

and display system, an EXIT command is given. 

A Sample .Session 

The session depicted in the appendix is a derived example* designed to "show 
off" various system features; thus it does not necessarily depict the. way the 
system is in fact used at Dartmouth College, . However, the data are taken from 
* our current personnel information systems and do reflect the current status of . 
the college. Two distinct applications are portrayed in the sample: first, a 
statistical surtroary of minority and female coii?>osition of the college's support 
staff is done, showing the sex and race distributions in various job-related 
and wage-related classifications; second, a depar;tmental display is presented, 
where senidrity is defined, and the display is based on a person's seniority 
in the department. 

If we dissect the sample, we find that the first three commands are infor- 
mation-gathering in nature.. They show us the range df data bases from which we 
may choose, the attributes in a particular data base, and the definitions of 
certain selected attributes from that data base. The fourth consnand shows a 
RETRIEVE commanc^, in which we are retrieving from the STAFF data base seven 
attributes'. The next series of commands involves cross-tabulations and frequency 
counts enabling us to determine the composition and distribution of minorities 
— and women -in this particular segment of the co]*ege's labor force . An analysis 



of these data is left, to the reader. 
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Beginning at the eleventh conatiand; we are narrowing the scope of our 
analysis to a single department (the Data Processing Center staff) , defining a 

person's length of service as a function of ' his -date of hire and the current 

'I '- 
time, defining his tenure as a function of the date on which he was promoted 

tp his current job, then sorting on tenure and displaying all; information in 

the working "data base aboU^ the' individuals in the data-processing department. 



DATft BASE STRUCTURE • 

A data base is a structured collection of inf oration. For example, a 
data base may contain biographical data about individuals, financial data about 
the institution (or some segment of it), or information about student's grades 
in courses. Our data structure is a rectangular matrix (or two-dimensional 
array) structure. Each row in the structure represents one entity or observa- 
tion of 'a data base. An entity may be a person, a financial account, or a 
course. Each column in the data structure is an attribute or characteristic 
of an entity. An individual's sex? race, or salary are exaii?>les of attributes. 
The value of attribute for an entity is called an item. See Figure 1 for a 
schematic of a data base. 

Figure 1 

FIND Entities/ Attributes and. items 



^ittributes 



name 



age 



rank 



address 



entities < 















* 

item 






item 
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F\mctionally, a data base is a collection' of files with an index, or direc 
tory file, locating each particular attribute in a specific data file. In addi 
tion to an attribute ' s_ name and fiLs location, the directory also contains in- 
formation about its protection level, its availability as a unique key to an 
entity, its length (mcDcimum) , and its type (whether numeric or alphanumeric) • 
Because of this type ;of struct^lre, it is very convenient to provide attributes 
with- meaningful names, such as RACE (for an individual's race) , HOURRATE (for 
an hourly wagfe rate>, or BUDNUM Ifor a fiscal account's budget number)* We 
Bave applied an eight character limit to attribute names, thus necessitating 
sowe abbreviations. The abbreviation concept has also been carried over to 
attribute values, a fact alluded to in the discussion of the DETAIL command/ 
to try t^ minimize the amount of space necessary to store data item values. 

The data files themselves are inverted images of a data batse. Logically 
each row of the data file is an attribute and each column is an entity. Thus 
statistical analyses of a series of attributes become ecisy retrieval tasks — 
the system is required to retrieve exactly the quantity of information needed 
to perform the task. Obviously, an ©nployee profile requires retrieval of all 
information for all employees, an expensive task for a single profile.* Th^se 
data files sure direct-access files, stored on magnetic disk units, to iqinimize. 
the search time necessary to locate an attribute and silbs'equently read its 
item "v^alues into core memory. 

All data, irrespective of type, length, or protection level, are stored 
in the logical attribute blocks within the data files. Data of any of these 

* This quirk of the system fs currently undergoing a dramatic change. Effec- 
tively, the RETRIEVE command is being altered to allow a' selection expression 
as part of its argument list, thus allowing a selective retrieve of the sub- 
seqxaent attributes based U^n the selection cri,teria. 

.1 /O 
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types may be stored in the same file, and the system will recognize its pecu- 
liarities and decode to a valid data item for the working data base. Thus 
sensitive protected data, which may be either string or numeric, will be de- 
coded and tinpacked if necessary to provide items for the user (see'Figure 2). 

PERMANENT DATA BAS'E 



SURNAME 



DEFT ' SALARY 



SEX 




WORKING DATA BASE 



SURNAlffi " DEPT SAL SEX • . 

. ' Figure 2 " / 
Relationship Between Permanent 'and i^prking Data Bases 



Once xetrieved^ the working data base* Is again organized as the standard 
rectangular .matrix. Additionally, the working base includes an order list 
which as created by the SELECT and SORT procedures an^ is* then used as an in- 
direct pointer to the working data, base by all other modules (see ?igu;:e 3) . 
This is c^one €o alleviate the time-consuming problem of copying the complete 
working^datSi base whenever a subsetting or reordering of the data base is 
requested by the us^r. , 
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Figure 3 . 
Working Data Base Structxare 

Painter LisV Working Pata Base Entities 

- .• ' ■ • - si 

Surname 

3 SMITH 

4 JONES 
2 V , BPOWN 
1 " ' DOE - 

This pointer list orders the working data base 
alphabetically by surname* ^ 

4, 

CRUCIAL ISSUES < 

Before FIND could he regarded as an institutional tool for the management 

of information, a number of procedural issues had to be solved. One of the 

N - 

earliest -issues was that of the definition of institutional data. In the 
1973-74 academic year,' f. task force directed by thfe Institutional Research 
Office surveyed the college community to ascertain what data elements were 
currently being captured, the form they took '(machine-readable or not) , how 
they flowed through the various offices of the institution, and also asked the 
question of what other data elements were necessary for the general information 
needs' of the college.. From that task force, a series of working papers listing 
and defining the various elements of institutional data were prepared. The 
FIND staff, in coniliinction with various offices around the campus, has made 

heavy use of thJ^esults for the capture of data in FIND-accessible formats. 

•r 

A second issue tp be resolved was the treatment of sensitive data. How 
should a person's salary be .protected from ^We prying eyes <5f his counterparts? 
The scheme which evolved for protection of sensitive data places the complete 

4 

burden for secrecy upon the individual offices 'with need to know prbtected in- 
formation. An encodingTdecodinCf scheme using a word as a see.d to a random ^ 
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number generator \i§ls developed whereby the seed word was neyer stored in the 
computer. *,If'a user loses a data password, there is nothing for him to do but 

^ " V " ' _ 

recreate' the passworded information from its original sources 1 

*The enciphering teqhnique works in the following manner/" Since' FIND's 
data Records are' stored ^in an inverted structure on disk, all^^nsitive data 
of parliicUlar type are jstored in contiguous locations. Thus;' a sensitive at- 
. tribute, such as salary, i§ stored as a series of n-character values. If 
salaries are five digit values and there are 500 people in a data base, the 
string of salary information will be 2500 characters in length. Given the 
d,ata packing technique employed, this information is stored in 278 contiguous. 
36-bit wordd 'in t;he' FIWD system. 

The data password supplied by the user is an eight character (72-bit) 
quantity. This' password becomes the first in a series of 278 pseudo-random 
nximbers. from each of these pseudo-random numbers 36 bits (ohe word) are ex-*' 
tracted and used to decode one word of the salary data/ (See Figure 4 for a \ 
schematic description of this technique.) The-decoding operation is an 
"exclusive or" applied to the encoded word. Because this operation is a re- 
versible transformation, exactly the same procedure (and the same 72-bit pass- 
word) is used to encode the data when a data base is created. [1] , 

' ' n ^ ' - 
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USER-SUPPLIED PASSWORD BECOMES 
FIRST IN PSEUDO-RANDOn NUMBER SERIES 



^ 



TRANSFORM USING FIRST 

* • ■» 

RANDOM NUMBER ' 



J 
I 



APPLY J^NDOM 
NUMBER GENERATOR 



DECODED' 
• • SALARir 




I 



TRANSFORM USING 








— > 


VJORD^ 2 


S^^D-RANixDM 'NUMBER ^ 








# 


* 


# 



TRANSFORM USING, LAST 



RANDOM NUMBER 



LAST WORD . 



t 



' Fiqure 4^. ^ 
''find Encipheriridf^^Technique 



178 



OLD DPCLIB**^:FZWD 
READY « 



' Appendix- I , 
A Sample Session. 
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RUN , 
FIND 



(COMPILED)) 04 DBC 74 08:26 



PRIVACY WARiaiJG. 

FIND HE-RK! 

? LXPLAIW DATABASE 

DATABASE. 



40 



0> ' 



Presently (2/11/74) tliere arp twelve <iata bases publicly available^ 



to users of FIND: 



ADMIli 
ART 

yupGET 

' 4 . SERVICE^ 
Sl,CAU 
SPACfi 
: STAFF 



Adnj^istrative-'' Officers of ,D(artmbuth College 
Catalog of College-owned Ar£ Objec^ts ■ 
Carrent^Year Budge.tr^ty ^Information for* tlv^ College ^ .v 
Biographical data 04^1 Dartmouth ^^^dents. Class of 1977 
FIND Ddmonstra-tion^*b^a Ba'fee — DtSS^' Inc. • ' ' . r. 

Khdowments^ of fc^l§ Colle§fe,^ and. thea^r Budgetary 6istsri?fautioh 
, Fapulty MemBers of Dartmouth and i^s Associated Schools 
Dartmouth's Temgftrary Erqployees * • ' ' . 'v- 

Dartmouth/^ Sery*fj?^ Traces fimp^yees ' ' . ' 

Educational Firjjancing ,by ^radua'tes of Selected I-r)stit'utions 
Inv.gntory and/ utilization. ^ College Building Space (2^)' 
Daartmouth^s^ Non-unionize(^"staff* Employees * : 



? at'jjribOte's .stafT" 
staff attributes 'are; 



BRTHDAY . 
/■ EMPTYPE 

• PARTFULL 
STATMNTII 

• MAILSTE " 
, , GRADE " 

MIDIUITS 
. hOMECITY 
EEOCODE' 
. FULWUM3P 
WORKADD • 
MAlLADDl 
QRATNOW + 



13'RT,HMNTH 
FINDNUM- 
•RACE 

- STATYEAR 

MAILZlH'^ 
SALAlWWP* 

• au^'Fix 

TOMES TE ■ 
■ REPOfe^ 

fi/Llnu^i3 

WOCITYST 
COLEDSP 
'SAtAlioW +• 



BRTjlYEAR 

.iiire'oate ■ 

•RANKDATi; 

UWIVCODE 
, FRSTNAME ' 
■ EMPNUM 

SURNAME 1 
; • liOMEAW 
■ ■ H INBOX 

SUBDEPT 

1K3MEPH0N 

workphon 

~*tVAL74- + 



■ CITIZEN 
MArLA€>D2 
REGTEMP 

coiSLgod^ 
fulnumip 
socsecno 
; t^;rmdate , 

FULLNUMl 
MONTHS ' 

■ DIV 

' JOBTITLE 
■ DEGRHIGH 
EV4L7«3 + 



EMPSTAT^ 

MAlL'dlTY 

SIS( ^- , . , 
J'RSTINIT 
XULNU^2R ■ ^ , 
■j^R^WK C . 
'TI'Ia 

FULLNUft2f'( 

spq^jsnAm 

VISA 

nOURRATE+ \ • 
HOMEZIP / 



INDICATES. PASSWORD PRQTECTION 
fcKJC lfjDICATES UNIQUENESS 
^' ''""uG Nls' ' •' ■ ' , 



Vol 



179 



? dktAi-l eeocode, .grade 

eeocode ■* ■ > x_ 

This is a one-digit numeric code to indicate »tl>e 
individual's determination in accordance to "the 
standard classifications under "Equal Employment 
Opportunity" classifiCrations , as- follows:? 



CODE , DESCRIPTIONS 

•1 Of f icials ,and Managers 

2 • Professionals 

3 ' Technicians 

4 Sales Wprkers 

5 Office A Clerical 
.6 * Craftsmen (Skilled) 

7 Operatives (Serai-Skilled) 

8^ ' • Laborers (Unskilled) 

9 * * Service Workers - 



I- 



GRADE 



A two-digit numeric code indicating the 

individual's presen'E "gr^de , as per €Re StaTf ' - . ---^ 

Rersonnel .Classification System. . 

DONE 

? RETRIEVE STAFF, GRADE, EEOCODE, RACE, SEX, DEPT,HIREDATE, SURNAME 

*RET: 7 ATTRIBUTES RETRIEVED FOR 914 ENTITIES, LAST MODIFIED J.1/11/74 

DONE , ' • • ■<>,','■ 

? XTAi3 I^EOCODE,STD ■ ^ 
EEOCODE FREQ 



0 


6 


2 


^■il9 


3 ' 


■ 138 


5 ' 


' . 594 




. ' 12 


7 


6 


9, 


'* 37 


* 





914 IN: SAMPLE, 2 EXCLUDED. 



DONE 
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? XTAB SlSX,.STD,EEOCODi:,SyD 

• EEOCODE * . 3 ' 5 9 

SEX- ' , 

■F '72 561. 24 

•M. 66 ■•• 33 13 

' 914 IW SAMPLE. .2 EXCLUDED. 

DONE 

?' SELECT EEOCODE =5. 

*SEL: 594 ENTITIES SELECTED 

DONE 

? XTAB GRADE, STD 
GRADE FREQ' 

Q- ' * ,2. 

1 ■ 20 • 

2 • 56 

- 3' 104 ■ » 

■4 ' \ .69 • 

'5 t- ' 165 

6 31 

"7/ •. 99 

8 . "11 

9 5 35 ^ 
11 ' : 1 

t 

594 IW .SAI4PLE. 0 .EXCLUDED. 



DONE 

? XTAB RACE, STD, SEX,. STD 



SEX 


F 


M 


RACE 






c ■ 


552 


■ 30^ 




0 


1 


B 


5 


1 


S 


1 


- 0 


A 


1 


0" 




594 IN SAMPLE. 3 EX«AJDED. 



DONE 
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9 RESTORE 
*RESv 914 ENTITIES RESTORED ' . 

DONE. - " . 

? 'DEFINE SENIOR = 74l'231 - 'HIREDATE 

DONE • • ^ 

? SELECT DEPT = "DPC" , * . 

*SEL:^ 12/ ENTITIES SELECTED ' . 
DONE * , ' • 

? SORT -SENIOR . • ■ s ' ^ " , i 

DONE ■ . . ■ . 

' ?• PRINT SURNAME, HIREDATE, -SENIOR, GRADE J EEOCODE, RACE ^ SEX 



3.81. 



"SURNAME 

MARTIN 

HANNAH 

jbRDAN ■ 

GUNN 

CHAP'lW 

FIFIELD 

MARLER 

G00l5AUE 

STILES 

HOOSE 

BENHAM 

lesker 




HIREDATE . SEN! 



EEOCODE , RACE SEX 



661101 


140130 




3 


' C 


M 


620103 ■ 
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Appendix II 
: FIND Commands 

Infdm&tive Commands 

ATTRIBUTES' li^ts attributes in a requested data bas6 

DESCRIBE provides brief explanatioij ofc an attribute ■ 

DETAIL prpvides complete explana^on of an attribute . 

EXPLAIN provides brief explahation of commands and keywords 



Primary Commands 
PRINT 
RESTORE 

RETRIEVE - 



SETTECT 
*SORT 

STATISTICS 
STOP " 



displays a list of attributes . ■ 
restores ^ working data base to its original 
non- selected/ non-sorted state 

accesses a permanent data base- and extracts attributes for 
a working data base . * ' 

, selects a subset of the working data base, according ^xi • - 
speci'fied criteria 

sorts the working data base according to specific attribute(s) 
' provides summary statistics for an attribute 
terminates a se?5sion with FIND 



•Advanced Commands , ^ * ^ ^ 

CORRELATION provides corf*elations between two attributes - 

' 'define' ' allows creation of a new attribute by combination of 

existing attributes and constants 

*PIT " allows linear or exponential regression analysis 

FORMAT provides flexibility in determining output format 

, ^ allows one- or two- at tribute, t^ulations ^ 
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Miscellaneous Commands » 
COUNT 



DEBUGS > 
EXEdUTE 

labe1> 

; LOAD 

OUTPUT 
» REDUCE 
RENAfffi 
BOUND 

SAVE 

SCI^TCH^ 



provides a summary of attributes and entities in the working 
V 

data base * ' • 

prpvides a debugging aid for FIND personnel' . ^ ^ 
specified a file from whigh FIND commands will' be read and 
exe'cuted . * - ' * , 

inserts text into 6utput * - 

reads specially-formatted files to recreate a. working data 

base " ' • . » 

specifier a file* to which output will be directed 
s-hrinks working data'Oase to entities currently selected 
' changes name "of afTa^triButenn v^orkxng data base . — 
3founds numeric attribute to specified places- (forcing 
alignment c^f^decimal point) ; , * ^ 

stores ^ copy of current working data base in- specially- 
formatted files 

erases some dt all attrij^utes frotn, working -data base 



Maintenance Commands 



UPDATE 

ADD 

ALTER 

DEBUG ; 

blSE^AY 

DROP 



initj-ates a maintenance session ^ 
* adds an entity to working data ^se ^ - • 

' \ changes , the value of ah item i^n wojrl^ng data'base 
provides a debugging aid for FIND* pe;rsonnel 
prints, selected c^ttribute. values for an entity* 

''^^ts^eletes^ an entity from working data base 
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ECHO 

ESTABLISH 
EXIT 
EXPLAIN 
IDENT 

LOG ' 

MODIFY 
jSCRAt§H 
STOP 



0 * Vol. ^11 

"parrots^ back"- the most recent changes performed by ALTER 

or-MOqiFY . V ^ . * . 

pteatesTlil^ in working data base .for spetified attributes 

terminates a mairr^Sx^ance session * * 

explains commands and key words ^ 

'/ c 'I 
specifies list, of attributes to.'use for identification 

specifies name of file to record changes for subsequent 

a£>plication to permanent Qata base 

changes items for specified entities 

V 

^ • erases contents ofjspecified file ' 
tei^ni'nates a session with FIND 
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A MODEL FOR UNIVERSITY . COMPUTER CENTER BUDGETING 
* John J. Falcone, Director 

. ' Joseph* A. . Reitty, Associate Director 

Anthony F. Graziano*, Assis4:ant Provost for Budget and Analysis 
University of Delaware / Con5)uting Center 
Smith Hall, Newark, Delaware 19711 

Allocation of computing funds in universities is a difficult 
task, especial 1;^ in times of tight government arid state budgets. 
At the \jniversity of Delaware we have come through a two-year period 
*"of high development of administrative systems. This development h^s 
'produced many new systems.- This paper presents a ^simple matrix which 
is used for budgeting the machine time, people, and equipment necessary 
to maintain and enhance these systems as well as to develop new systems 
in an organized fashion.*' ^ . 

1. INTRODUCTION 

The internal allocation of funds for 'computing is a difficult 
task and oftentimes is confusing to the user of computing services. 
Budgeting and allocating the coja^ting re^source i^ often treated- as 
a single-dimensioned entity while, in fact, it is jnulti-dimensioned . 
One dollar of computer funds allocated to a user can obtaifi produc- 
tion time for an established system; maintenance (programming an'd 
machine time) to a system;^ or the programmer and machine tiifte to 
develop a new system.^ That same dollar could be spent on terminal 
hardware intended to^ enhance the operating, maintaining or dov^lopinc} 

Figure 1 is a graphical representation of, the activities 
or parameters that might better define the allocation of the computing 
resource . . * * ^ ■ , 
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One possible distribution 
^ of computing dolla^ 



Production 



Figure' 1. Computing -Dollars by Type af Activity, . 

Previous allocations of the University of Delaware coinputing 
resource and the proposed '74- '75 allocati(:m of that resource Ccin be 
represented graphically using the above axis to depict a two-year 
evolution of thet allocation from a high d^elopment investment to a , 
high production investment (Figures 2 and 3) : Unless we are prepared 



to sustain exceptionally large and continuing increases in the 
University/s budget for (Computing, Resources' Hevoted to investment * 
in the design and construction or * functioning applications must 
ultijnately be devoted to sustaining the intent of the investment, 
- And unless some continued steady-state allocation erf development and 
maintenance is provided to enable the . computing resource to r^new, 
and enhance its services over time, the whole cycle of high cost 
development will haye to be repeated periodically in a most inefficient 

• * ^ ^ ' m 

^ t 

way. The development, services of the Computing Center should be 
plahned as a steady flow of assistance targeted for thpse areas where 
^ the University as a whole will benefit ♦most. It cannot be a crash 
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program required every five years or so to plug large and imineckiate 
demands arising fjrom unanticipated needs. The steady flov^ of aew 
development should result from 'Computing Center leadership guided by ^ 
user dialogue and understandirig:^ The users must continually -participate 
in dialogue amongst tK^jivs.elves and with the Center; they must under- 
stand that the University ^nd its budget for computing is not a 
"fvinny money" key to unlimited and unconstrained demand; and they 
must participate in the determination of what is best for the University 
as a whole even at.,.the expense of their individural needs and aspirations 




Figure" I,. Dollars in Millions Figure -2. 



V 



^2. DEFINITIONS AND CONCEPT 
* , Table A defines the terms used in this discussion 



4 



Figure 4 is a 3 x 3 matrix which .represents the three activities 



involved in delivering computing services versus the resources required 
to accomplish them. 
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Figure 4. Activity vs. Resource Matrix 



A computer dollar _ representing somfe measure' of computing service 

' • t ' 

demand can be deposited in one of nine cells; i.e., we could invest • 

■ ■ ' ^ • . ■ . , - 

the dollar in people fo^ new development (Row- l) Column 3) oi\we ' . ^ 

could invest the dollar in machine time for production (Row 2, ' ' 

Column 1) or any o,f 7 other possible ways. However, a wise investment 

m computing dollars- considers the trade-bffs implicit in" selecting ' 

any one of these activities over, the others as well as the resource-^ 

cpst to achieve .them. Insofar as the University is aoncerried, the 

computing resource is limited by tfife--^ combination of people, machine 

* ' , »♦**.» 

time, and equipment which can be'purchased with the total university., 
allocation for computing. We, as administrators , ^ need to introduce 
users to these fact^ of life by allocating to eaql^ of them some 
.equitable share of and control over a piece of the tot^l resource.. 
And we nSed to monitor their' decisions as well as ; provide to them the 
best and most infomjed leadership ^yarilable thrpugh central coordination 
at the Computing Center. 
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THE PROCESS OF COMPUTER SYSTEM DEVELOPMENT 



us consider *the typical process of ^ new system development. 

' . ■ ' \ 

A specific need is i<JentifLed by a department or perhaps some 

universxty-wide problem \s perceived which conceptually would lend 

f 

itself to computerization. The development of such a system is 
usually considered in the form of a feasibility study. This* study 
considers the initial cost of system design, programming, and 
documentation as well as the on-going ^production (operating costs) ♦ 
Enhancements' or maintenance of the future system are not usually 
considered for it would be -difficult , if not impossible > to anticipate 
this activity. Therefore, have unavoidably built in the first 
possibility for a future budget overrun when the system reijuires, ^ 
later change or ^modification in its. production mode. 

. If the feasibility study is accepted, 'the development^ »vork 

» " » * 

begins. At this time, a group or, pro ject team is designated, ar 

schedule of machine time is developed, and any required special 

equipment is ordered. . . - . *' • , . . 

■ . /.'■ ••■ ... ■■. 

As the system is developed ,'^the actual machine requirement -for, 
future production becomes .evident . . JWhen the system r'eaches opei^^Jiiional 
st4tu^, the full attention of the prp ject" team 'is no^ ipnger required * 
and the people resoilrce required tp operate the system in a production 
mofle is considered in the maqhinS cost "overhead". Froductipn support, 
•correction ^of errors, standard kSypuncfiina^^tc^ , are also considered* 
in this mcTchine. cost for production. 
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When the system reaches .the production mode, a certain tolerable' 
level of enhandements or changes are exj3[ected. But these can be 
»serioijs and disruptive if the system has not ;been d^si^ned or 
implemented to meet claarly stated objectives ' of the user. If ? 
organizational policy is constantly, in a state of flux, a particular 
system may experience significant 'requirement for , enhancement or. 
modific.atiofi regardless of how well th^' particular^ user may have , ' - 
9J:iginallyi specified design parameters^ System flexibility that 
could have been anticipated in the^. planning and design stage, but 
which is not provid^ed^for in the ^delivered system, can well result 
in*high maintenance/ activity , user and community disaffection, af<d 
high costs of peoplfe and ^nachine resources attendant to modif icatijon 
of the system. . / . ^ , 



Flhaily, w\ien a multitude .o£ changes have so corrupted the 
original design, or .when the system no longer m^ets current policy - 
oi: needs, a demand, is created for its replacement. At that time, - 
we ifeturn to a feasibility study for a nlw comjfuter system including 
considerations of th5 costs as -well as new reia-tionships with other 
Existing systems that have been developed*'over t^e life span" of the 
system in qxies^tion. ^ ^ * ' 

r£ is not easy to determine when a computei; system has outlived 
its usefulness. Such a 'consideration must take into account any ajnd 

all ^systems in existence .at that' time or being considered for 

t ' * 

implementation at that time^ The proposed concept of a budget matrix 
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forces consideration of all interrelated costs and relates these 
costs directly to <the current inventory, of services and the 
•^'•WPl^nned allocation of the total computing resource • 

In addition to the project' development and operating costs of 

a proposed system, maintenance costs must be' considered or provided 

for in a manner which motivates stability and sound judgment. 

Maintenance costs are less deterministic th^n development and 
' . ' > ' 

operational costs, and to a large ext.ent, are a function of the 
user's total coitqputing resource available. It should also^be .possible 
for a knowledgeable investor to allocate one .dollar toward maintenance 

I- 

m order to secure a more efficient system, to reduce his ope^ratmg 

- ' \ 

costs m an area by, say, 10 dollars, thereby leaving 9 dollars 
worth -of compujting resource available to everyone for more develop- 
ment and/or mote production work. Overall cost effective utilization 
of the University's total computing resource can only be achieved if 
each user or subset of users understands the budgeted limitations ^ of 
the total resource and participates in the allocation of that resource 
to the functions of production, maintenance and development, 

4, USING THE ACTIVITY/RESOURCE MATRIX FOR PLANNING 
_ _ 

Certain areas of the Computing Center may never be directly ^^ 
allocated in this manner; e • g, Academic Services, Systems Software, 
'Indeed, "it may always be necessary and appropriate to repover the 
systems prograiraning manpower costs as production "overhead". 'The 
demands of the acadeinic community -^t this university are still in a 
state of change atid several new and large -requi&rements appear t6 be 
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evolving. / Until the Center is better apprised of ^he^current and 

/ * • ' ♦ 

future needs in thi$ area, it would not be prudent to allocate 
developmept and/or '.consultation costs. We do not know enough abput 
the need? of the user community and assi^gning thetee efforts in a 
rigid waV at this time may overlook targets of opportunity that bring 

benefits to the tptal computing comm\init:y ox a large segment of that * 

! 

community. * y • ^ 

Eventually/ how.ever, t|ie University community benefits from a 
planned allocation and utilisation of the non-production elements of 



the Computing Center tot,al resource. New development projects and 

major maintenance projects can span the significant portion of a 

year. The^ size of our Computing Center staff available in this area 

prohibits the wasting of any portion of that resou;:ce that can be 

tied up in meetings ay{d other discouf^e arising from the confusion 

^naturally attendant to tneeting crisis^ tequirements . The state of the 

' / \ - - ' , , ^ ^ 

economy also dictates efficiency. F®^^ the. sake 6f the total university 

^ / ' 

community, developrt(ental and maintenance projects must be planne^d with 
an eye tp^ard encouraging growth and efficiency ii;! -computing by 
allocating development dollars into the computing budgets of academic 
and administrative units who are now comparatively compute r~de s ti tuto . 
Ueveiopmert dollars must be expended toWard increasing the quality 
and quantity of productive systems in order to promote a positive 
growth rate of the 'University ' s computing community, j^d nintil that 
growth rate is known 'and intelligently anticipated, it is difficult 
to plan knbwledgeabiy. about future requirements. - 
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It is proposed that tha^ioundaries ^of administrative conlgmting . . 
be fixed for the coming ye^r, these boundaries." being somewhat flexibly 
-assigned to each Vice-President responsible for some specific set of 
services. In. addition to all^fcations for produfction costs anticipated" 
for each of his operating units', each Vice-President is ass-igned a 
recommended total budget for maintenance with which he catir 
(a)^inprea:se the . efficiency of existing systems in order to reduce 
future costs of their production outputs, or ^b) attack short-term 
problems arising from new external or internal demands, for information 
and controls.' In short, each Viee-Pre'sident has his own "mini" 
computing center complete with' people, computer '(pro-rated) and 
equipment. » " ^ ' 

Additionally, the Provost, as Chief Budget Officer,' has been 
assigned the development portion, of the total computing resource 
to promote block-by-bloc^c construction 6f the total campus planning , 
an& management information^ system. These funds are to be targeted 
for projects such as ^ace utilization, jnajor enhancements • in 
financial and stjudpnt dat^ systems , * and^ other , perhaps nonexistent, - 
operating systems necessary to the management o'f the University's \ 
functions . . ^ 



Graph I represents the allocation schema proposed at* the 
University of Delaware. 
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The plan, to date ,^ has met with favorable comments. It is of 
interest that each participant has developed an acute awareness of 
the nature of the computing resource. We hope to build upon this 
awareness an involved ai^d economically conscious user community.. 

I 
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TABLE A 



4 



1> Resources - ^that which is necessary to develop, operate and 

» . - ' *t 

. maintain a computer system.. 

^ 1.1 People '- programmers/analystfe/systems personnel who will 
♦ 

design, operate and change, compute^ systems . 

1.2 Machine - the amount of computer time and pro-rate^ 

» » 
operations personnel necessary iYi the running of existing 

systems, effecting changes or enhancements t'o existing 

systems, and the development of new* systems. 

1.3 Equipment - all peripheral (terminal) equipment necessary 
primarily to. run on existfjig system but also needed^^or 

•design and changes to proposed or existing systems. 

2. Activities - the three components necessary to create , use and 
change a computer-based system. 
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2.1 1 Production - that activity which deals with the successful 

J . 

operation of a previously developed system. 

2.2 Maintenance .- that activity which deals with short-term 

changes ^or enhancements to an,* existirfg system. 
* 

2.j Development - that. activity which causes a need for a • 
computer-based or computer assisted system to come into 
being; i.e., design, prbgramming, documentation, etc. 
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ADMINISTRATIVE INFORMATION THROUGH ON-LINE' APL SYSTEMS 

' * D. D. 'McElroy 

Office of IJnstitutional Research 
'The University of Texas at Dallas 
. Richardson, Tekas 7508o 

E. E.. Payne 
Director of Planning^ and Management Systems 
The University of Texas ^J: Dallas , 
'Richardson, Texas 75080 



The University of Texa^ at Dallas is a developing < institution. » In 
preparing for a new mission, that of starting a large undergraduate prc5gram, 
the administration has found it necessary to solve many new planning pisiibiiems 
while, at the same time, continuing to operate a complix program of sponsorj&d 
research aijd graduate studies. The Office of Institutional Reseai;ch harr 
assisted the executive administration by (l) conducting special quantitative 
studies that i-equire qui(jk answers ; and, (2) developing information sys\.ems 
that make mafiagement information available on short notice. 

Thi§ paper briefly discusses the mode of operation of the Office of 
Institutional^ Research and describes several studies in which on-line informa- 
tion systems were developed. The information sys^feems- described include: * 
F,acilities Management, Evaluation of Service Organizations, UTD Economic 
HLanning Model, Classrocm Utilgjzation, Ans^ysis of Coimnunity College Data, 
P.eport Monitoring, A Text Generation System, and Budget Analysis, 
1.' INTRODUCTION " . ' 

The University of Texas at Dalla,c is an inct-itutlon in th^ firf?il 

ctages of a complete • metamorphosis.' It wac ^^'^tablishf-d, and ha:; on 

internationally recognized for over k decade, an ^ leading/ recr^ai^ch rouTHiaUofi 

ft - » • , fc 

withf teaching activities only in graduate studies. In 1969? the.nrope of the 

institution was significantly expanded to include degree program studies for 

undergraduate students. This yeari^ the University is ccSl^leting the final ^ 
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stages of a large building and staffing program, and is, preparing to'o^fe^i 
for U,000 iindergraduates in the fall of 1975. 

In recognition of the significant planning and, development problems that 

V 

faced the institution in preparing for its new mission (while at the. same 
time continuing to operate a complex program of sponsored research ana • 
graduate studies), three years ago the administration at the Uaiversity 
orgg^nized the Division of Planning and Management' Systems, ,( see Figure -l). 
This organization included a function new to the University, the Office of 
Insti"futional Research, Institutio;ial Research was charged with the 
responsibility of providing special quantitative staff support to the 
executive administration (the President and Vice Presidents). The Director 
of Plarjning and Management Systems (who^'also served as the Director of 
Institutional Research) established the following operating g\iidelines for, 
the new organization: ' 

Institutional Research will function along the lines of a small 
corporate operations research group. It will serve the Offices 

« 

of the President and the Vjice Presidents. ' . ^ 

. Emphasis will be placed upon solving managerial problems. Studies 
whicji have limited value (except for publication) will be 
• discouraged. 

Large ^ long-term projects will be limited to no more than 50^ 
of the man-effort. Experience has shown that solving numerous 
small to medium size problems *v;ill p,ssure a broad ^ase of 
' ser^/ice and a continuous high return^ for the effort expended/ 
. Staffing should be limited so that there is*" always mpre "critical" 
work than available manpower. This produces a natural selection 
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^ocess (for staff* organizations) which helps to assure that 
unimportant projects are seldom initiated. The staff will 
consist of a small, permanent core of professionals which will 
* . be supplemented by graduate 'students and faculty on temporary 

assignments. , , > > - ' " 

- From tjiie point-of^view of the executive administration at th^ University, 
this mode of operation has proven to be very effective. Numerous management; 
problems have been effectively dealt with because managers were furnished 
the necessary information on a timely basis. This tlm6ly information was 
fre.quently made, possible because of the ability to quickly develop and use 
computerized on-line informaticjn "systems. This paper explores examples of - 
Administrative Information Systems that have been developeij and used at 
UTD. The systems that' are discussed are: \ ^ ' 

Facilities Management 

/ • ' ' - 

Evaluation of Servip4 Organizations ; 

Um Economic Planning Model 



Classroom Utilization 
* . Analysis of Community^ College Data • ^ - 

Report Monitoring- • ' ' , . 

\ i '*A Text Generation System * /' K^- / . 

. Budget Analys^-s 

Several of these applic atioris • are rather common place, but are of interest 
in- providing a spectrm of the information systems 'th^t have been developed 
and found to^^^^fiTgh utility. • ' ' . 



— a ; ^ ~ : 

"Better information -tkies not lead to better decisions, unless the 
'managers are highly capable and" -they have the opportunity to taite' 
advantage, of the "better"' information." .-. ^ 



2. • llQUiFMENT AND' FACILITIES 

The' small staff' of' the Office of Institutional Research wor;^s closely 

t\ • » ^ -* 

with .the 'executive administi^ation. In effect, the Institutional Research 

staff has fre^^ueritly. become the conduit which i^^BEBjpAinistratlon access 

to* quantitative management information, ' The babic-computing facility used 

by Institutional Research to carry out its' activities is an IBM 370/l55, which 

^is Utilized thr'ough either an interactive t^mdnal, or a Remote Job jfentry 

(baCch) terminal. • * ' \ > — * ^ 

Althoi:igh several different computer languages, are used, the' greatest 

succesfe^ 3^ meeting the demafid of quj^kly developing management information 



systems has been with APL. This language has several advantages: 

. , ' : / 

. . * Easy to use ^ * 

. Can quickly devel9p systems and bring into full operation 

* 

. ' Has* powerful matrix operators which are useful .in modeling 
All of the applications discussed below were' developed using APL.* 
3: FACILITIES MANAGEMEICT • 

• Th^^lanning, control, and allocation of space was i significant 
management problem that was growing worse. An on-line "PacTIities Management" 
system was developed and 'implemented to assist administrative decision raak^.rs. 
Some, of " the features of the- system are; ^ ' , 

♦ A complete listing of the atfribute.^ (nizo, qulpmr-nt, ?A.'l;:l//rirn^-rjf., 
etc. ) of^ any one room, or of all rooms, is alwayr; availablr- fr<'3m . 
n terminal. ^ ' ^ ^ ^ ' * . • 



APL is a language originally developed by Kenneth E. Iverson knd described 
in his book, A Prograngning Language . [U] ' " . * * ^ 
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A "formula" model has been deVelbpId to assi^ in the annual budgeting 
Space. Budgetary' i^its ^re^MloQ.a^'bed\>pacje on -a "formula basis** 



(standard), 'Formulas are bas^d'upon personnel,, semester , credit hours, 
research, 'and equipment. • ^" j; . j 

* . A special request from a budge tary, unit , resulting from an*\Hifbreseen 
event, for additional space ca:n b^ instantly compared gainst, botb 
"formula" ( standard)^ &n({ the iirstitutional average for similar 

> 

^ budgetary unitjs . . *. - ^ * 

. The* system provides xthe ability to "game" or to project future space 

needs Sased upon e 03:011 ment and/ staffing' projections. . ' 
The flowchart in Figure 2 -Illustrates t:he. logic of the Facilities 
"Management Syst«n. A more detailed description of this ^stem is provided 
in the. Proceedings, of- the 1973 CAUSE National , Conference ; [l] 
k. E^/AhUATION Ok SUPPORT DE PARTMENTS ' 

: { ' 

Since 1972,, at the request of the Vice President for Business Affairs, 

4 

an evaluation of support organizations has been conducted every six months. 
T&e first evaluation covered 22 suppo^ departments such as mail, supply, 
computer services, cafeteria, bookstore, print-shop*, etc. The evaltiation 
proved to be ^ useful source of information on both -areas of problems and 
exceptional performance. Since it was started, various administrators, 
.perhap5 .^^pedting a, problem area in their organization, have asked to be 
included in the confidential survpy. The last evaluation included 31 separate 
departjnents. * . . ^ * ' 

k,l description of the> Systen .^' The evaluation is based upon a survey of the 
opinions of the, administrative heads of the various departments that are 
Vufeer^s" of the siipport departments. A simple ^questionnaire allows the usor 
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to evalviate the support departments on a ^cale of 1 to 7 on (l) effectiveness, 
(2> efficiency 5^3) cooperation and tact, and, {k) extra effort/ There' are. 
two more questions which- ,are'! used to indicate the level of interaction and 

dependence of .the .liser'pn the .support department. Comments are also encouraged, 

* ' ^ ^' ' ' ^ . . 

^An evaluation pajckage i$,s'ent to the administrative head of each organization 

♦ " - ( • / 

at UTD, The' a^nrstrative\head is encouraged to perform thg evaluation by 

way of a bxi^f panel discussion with the members of his organization that 

• / / ' , ^ ^ ' 

actually ' have contact with the Support departments, ^ 

* ' ' *' # , 

h,*2 Re ports > The^ questionnaires, are keypunched and read into an APL file, 
— ^ . - r < , 

The AfL prpgrain theQ j)roduces five reports *on each support department, 

* • \ ,^ ' ' : ' \ . 

1, Analysis of Data , This*" report give^ frequency respons-e do\inti> 

\ mean, standard 'deviation, and" tests for statistically significant 

deviation from aveirage evaluation. It also reports the scores 
from, the pr^yio^s evaluation and the percent change, ^ 

2. Analysis of Data of Those Organizations Highly Dependent on the 
Support Depstf-i&ments , This is the same repqrt as -above only .using 

' those organizations highly dependent on the support departments, 
3/ index gfft. Evaluation * This report calculates two index numbers 
* for eacH question and ejach support department. The index for a 
department is equal to the average, score' for the support department 
divided Ixy -the. overall* average for all support departments, 
' Therefore, an index of 1 is an average rating, an indeX' higher / 
th^ja 1 i"S above average Vating, and an index Iwer than l^is 
a below^ average rating. . A summary report ranks all support 



departments against each othei*. 
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' k, CoatDarison of Current Ir^^ex Ratings to Previous I ndex Rating. This 

{ . '■ . ^ ^"7 ' 

report compares each support Wepartment ' s overall index with the 

* .'.•'/ ^ ' ■ ■ ■ 

•■ * ' .r^anMng of the previous- six /months and" gives the percenta^ change.' 

5." Comments. A summary' of th/ user caitoents is printed out 'for each- . 
department* 
5. UTD. ECONOMIC PLAHNIMG MODEL 

At The University of fexas Lt Dallas several jfodels have peen used to 
assist the administratibn in ec6nc5nic planning. UH) has been an especially 
; fertile area for the use .of this type of quantitative" management tool since 
the Institution wili grovf/in size from-300 students in 1973, to 700 in 197^,^ 
^ 5,000 in 1975 Omost of thes^ arfe already admitted), to 12,000 by 198O. 
This student growth' m6ans tremfendous growth of staff and facilities, which, 
in turn, meaps that the admi'nistration has the opportunity to dete?rmine (by; 
their deci#6ns) what the institution will look like by the "end of this 
decade. In 'this enviroi*ient, quantitative planning modelp have already proven 

- invaluable in assisting ^xecJutive administration in (l) determining requirements 

1 ' . * ' / 

(facilities, funds, facttLty, staff); (2) investigating alternatives; and, 

(3) determining, .and planning within, fiscal and facility constraints 

imposed by the State Legislature. 
/ 5.1 NCHEMS ^fodels . The .Office, of Institutional Research experimented with 
' \he planning models .developed by NCHEIC.* Although these provided sbme useful 

ideas, which.were added ..to the,basic tTTD planning models, the NCHEMS models. 
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See References [2, 3]* ^ ' * * 

The definitions in the OTD feconomic Planning Model have been changed to 
be consistent with the' te'rmonology used in the NCHEMS products >mich have 
become virtual standards. 
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were-fcftind not to be 'usable at UTD because: (l) UTD planners were already 

accustom\d (spojled, perhaps ) 'to the UTD iijteractive models which ' provided 
\ i 

• quick response; (2) the KOHEMS batch models cost several times more to run; 
(3) the Ifm models (written in APl') could be easily altered' to represent * . 
new questioiis; -and, (k) the UTD models cdhsidered the Texas "Formula Funding 
System" and generated facilities requirements.. These observations do not . 
reflect badly upon -the* NCHEI« products, but rather illustrate what NCHH4S 

J ' i ' ' 

itself feays that their Tno^^pls arp a tpanhing tool and a point of departure 

for serious users of quantitative planning models. 

5.2 structure of UTD Economic Planning Model . The UTD Economic PlanniTig 

Model, is an approximation of 'the financial relationships of students, faculty, 

staff, facilities support,' and money. Some of the important elements are: 

1/ The objective of the model is to assi^" in the development of a 

viable financial plan "by answering vario\is types of "what if" 

* questions. ' ' . . 

- ' 2. Parameters are "cpnstants" which are given or set hy the decision-i 

. maker. Parameters represent the control that the planner (or the 

environment) has ovetltho situation under investigation. "Fhey 

repr^^ent policy decisions, courses of action, or ^Ui<- cnvironmr-ni.. 

, . , , , Examples of -typical x>arameters in the models' are: 

^ ' > ,< • * 

V . FTE student enrollment ("by degree program, hy* student level) 

, ' , Faculty workload ("by discipline, by level) 

^ Facility salaries (by rank<by discipli/ie) 

^ \^ Faculty rank distribution (bjr discipline) 

♦| . • ^ Class section size (by discipline, by level)' 

ER?C ■ 211 
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, Texas State Formula Funding levels 4 

♦* . ICLM (induced Course Load Matrix) - • , 

^ Parameters may change, « and even becane "output variables ^ * 

ia. depending upon what is being investigated, 

^ 3« ' Output variables are values that a decision-maker wants to kr^w 

(results) and which ma^ vary .l^ecause of different policy decisions 

or courses of action. Although these may change (depending upon 

v>hal is/oeing investigated), typical 'output variables are:'' 

' . Semester credit hours produced (by level, by discipline) 

. FTE faculty (by level, by rank, by discipline) 

/ Faculty productivity (SCH/FTE faculty; by discipline) 

. Student/Faculty ratio (by discipline, by level) ' "C 

^ \ * 

. Faculty salary requirements (by rtok, by discipline) 
h. The logic of the model is a mathematical" description of the relation- 

ft 

ships between, and among, the parameters and output variables. Tl^e ^ 
logic is briefly indicated in Figure 3. , , ' ^ x 

6.\ OASSROa^ ITIILIZATIOTT niFORI-IATIOH SYSTn^l 

Efficient use of classroom space has been a major concern — theiie always 
seenSis to be more classes than ,classrooms. This simple information cystem 
provmed a means of both ixtventoring classroom utilization and comparing^ the 

\itlliz&tion a^inst a reccanmended* standard for each typf: and nize of cJLar. :room. 

\ * ' ' 

In thia cystem the following definitions are^uned: i * 

\ - ' ^ 

'a.\ Weekly Room Hours (WRH) , Weekly Roan flours is the number of iiour^ 

•lurin^^ 0'i€ weey. for which a room is available. ' ' 
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ICLM 



AVERAGE 
SECTION- 
^iZE 



FACULTY 
WORKLOAD 



FACULTY 
RANK 
DISTRIBUTION/ 



AVERAGE 
FACULTY 
'SALARY 



I 



SCH PRODUCED 
= ENROLLMENT 
PROJECTION X 
ICLM 



I 



FACULTY CONTAa 
HOURS = SCH 
PRODUCED -=7 
AVERAGE SECTION 

SIZE^ 



I 



FTE FACULTY 
= FACULTY 
CONTACT HOURS 
-f FACULTY LOAD 



I 



FTE FACULTY BY 
RANK : FTE 
FACULTY X FACULTY 
RANK DISTRIBUTION 



I 



COST OF FACULTY 
- FTE FACULTY BY 
RANK X AVERAGE 
FACULTY SALARY 



I 



FORMULA GENER- 
ATED INCOME=SCH 
PRODUCED xST>^TE 
FORMULA RATES^ 



SEMESTER 
-^CREDIT HOURS^ 
PRODUCED 



PROJECTED 

"•7 FACULTY BY 
DISCIPLINE 



fPROJECTED 
FACULTY BY 
RANK AND 
DISCIPLINE 



FACULTY 



COST 



/COMPARISON 
InF COST OF 
FACULTY VS 
FORMULA GEN^ 
ERATfD INCOME/ 
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b. Weekly Student Contact Hour (WSCH)( , Uae of the room during one ^week 
by one student for one hour, (if *a 3-hour class section has 30 
students, then .that section uses the room 90 WSCH,) ^ 

C-. Station • Station is a place for one student. 

d. Capacity ♦ Number of student stations in.one room* 

e. Stgti(^n Occupancy , Station Occupancy = percent (variable) x number 
of WSCH. • ■ • ' 

f. Utilizutloii . ulilizati'on- --■ wSCK's/ (percent x capacity x WRH). 

In this information system, the parameters ^re (l) the Weekly Room Ho\a*s ^ ^ 

"(VTRH); 'arid, (2) the percentage utilization of statio^n bccupancy, Plannern . 

may estrablir,h titiliza.tion criteria (several sources recommend standards T^;]), 

and then cpmpare the actual utilization to the^e criteria (standards). For 

" • . 

example one m^ set a criteria of WRH = 30 and Station Occupsjipy = ,55 x'WSCHs. 

^Then, i!*a cSL^ssroom for a particular semester has a capacity of 28 and 
VJGCHs = 378/>Jie utilization would be 82^ (378/(.55 ^ 2& x 30)). 

Th^ Room Utilization System p^vides a roOm by room analysis and a total' 
utilization analysis. The room'*by roo"i analysis has proven particularly 
uneful in identifying^, roans of both hif^h and low utilization for oxceplion I 

•management (action). • ' 

-7. AmynlG OF LOCAL COI^^IMITY COLLEGK DATA ' , * 

UTD is an upper-level institution and will enroll many student:; from 
local community, colleges. The Pallas. County Community College System generates 
extensive student d^ta for all of its four campuses edch semester. These 
dati have been made 'ri/ailable to :JTD. Therefore^ an information ny :tem wa-: 
developed to answer questions about the community college students and to 

* a 



determine typical prpfiles^^oT these individuals. The "profile summary includes 
information on each campus," sucTi fe; he^dcxsunt;, total FTE; students , FT|,day^ 
and xiight students, percentage of students en±-olled in transfer and technical 

programs, percentage of si^^^^ vhich meet ITTD entrance r^p.remepts and a 

' ■ ^' ^< . ' "\ ^ ^"V 

^breakdown of transfer student^^ by?Epg3-Oi'«( V 

This analysis is perfarm&cea<ai..,^^Mestef.: .Also, ^ it lii planned to develop 
a student data base to analyze .trends^ Md compare to the p^^file of the, 
entering students. i ^ ./^ . / 

Sp far the' data have-- indicated' that the' entering stud^^t will differ 
significantly from €he "typical" college; st\!ident.^' This i^onnation has 
proven valuable in planning aeidemic programs , student li^^ programs , and 
student services. ^ 

In addition to using sthe .conjmunity. college data to^ticipate the type 
of student to expect, it is planned for this system to be -^^anded ii\to a 



continuing analysis ot the students that enter ITTD,. This/^11 provide both 
UTD and the community colleges longitudinal studies of sln^ents, which, will 
assist the planning and development efforts 'of administra^|ars. of both 
institutions. The cooperation of local community colleges has played an 
important part in implementing this information system. 
8. A REPORT MONITORING SYSTEM ' * S"^: ' 

One of the responsibilities of the* Of f ice of InsU^ttMonal Research at 



the lAiiversity of Texas at Dallas is the coordination df-all external reports 
for the University (i.e., HEGIS, State report, AAUP, i^tc), and the maintenace 
of a central file of all reports. In September and Oc^^Dber of this year alone, 
there were over 50 reports- involved. Each report moy r^^uire action by ceveral 

m . "'J .'■ * 

^2is ':i , 
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different departments. Keeping track of bhef?e reports and assuring that 
deadline ^^lates ar€ met has become a time consuming task. Therefore, 'a Report 
Monitoring and Scheduling System''S?fff^3?veloped. 

8.1 Operation of the System . When a report request is received, a secretary 
executes a program on an interactive terminal which will request Ifer to type 
in the necessary monitoring atnd scheduling information — report name, 
requesting agency, date due, and organization responsible for completion. 
From this point^^he system produces two basic reports. The first one is a 
"scheduling" report. . . - . 

The scheduling report may be run at any time fbr any month; It produces 
a b8LLendar of all actions to be taken that month. All externetl reports 
required are listed, the date tKey are due, the requesting agency, the UTD 
^Kiep^rtment responsible for the report, date the report should be sent to the 
responsible department, and the date it is due baqk tq Institutional Research 
for forwarr5ing (and copying into a central file). A typicatl portion of this 
report 'is shown below. . 
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« The other report produced i$ an End of Month Report, It refb.ects all 
actions vAiich have taken place during the month, or were duetto have taken , 
place, A sample portion shovdng actions taken on one report is shown lielow. 



V 



r ■ 



nilD OF rOUTll EF.VORT FOR: SEFTEf'-BER- 



REPOPT : 



2300-4 



PATF DUE TO DUCH': SEPTEMBER 31 
DATE SERT: SEPTFIW^R 27 

. • • • ^ 
DATE' DUE BACK To'lVST RESEARCH y OCTOBER 24' 
DATE RECEIVED: 

DATE DUE TO REGIS: OCTOBER 31 
DATE SEilT: ' » - 
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8.2 Comments . This simple system has turned a confusing and time consuming^ 
task into a -aimple routine. Involvement of administrative heads, to expedite 
late reports, has been virtually el jjninated. A centralized file and a 
centralized calendar has been created. ' • . 

9. A TEXT, REPORT. AND QUESTIONNAIRE GENERATION SYSTEM 

Ih the planning of undergraduate prograins for the University, the 
academic administration wished to receive advice from many people all over 
the country knowledgal?le in. their field and who had special interest in 
undergraduate education. Therefore, the Delphi method, developed original^ 

J • • . , ■ • ) 

.• 217 ; 



"by the Rand Corporation, was used.* This^jnethod required many letters to 

"be written; questionnaires to be' created for each discipline* surveyed; 

foUow-vip leisters to be sent; and second-round questionnaires to be created 

and sent. A Questionnaire generation system was developed to support this ^ 

activity; ^ ^ • • . 

* * * *^ * 

9*1 Description of the System , The system is designed so as to*be easily 

used by a typist working; at an interactive terminal. The first "step Xs to 

enter the names and addresses of the panel members. These can be entered 

continuously suid in any order. Each panelist and address will become a 

component of an APL file and hence have a unique number associated with-it. 

This will become the panelist identification number^ The "text- ere at ion". 

program allows the .body of the letter to be ty^ped, corrections easily made 5 

then run through an edit program to set margins, indentions, page numbering, 

etc. , . 

♦ After these data are entered,- no further input is entered. The "letter 

writing" program alphabetizes the panelist, prints the date, address, salu- , 

* * f 

lation, body of the letter, then stops* until th'e next sheet of paper is 

ii^serted an(J,Jbhe ciarriage returned. Envelopes can be also addr,essed, or for 
l8u:ge mailing, labels printed from th^ APL file through the high speed 
-printer. . f 

- PefhapsVthe;^nly original part of the system is a general purpose 
prpgram-'for ^reafir^ questionnaires. The questions are printed in any desired 
space on th^lef^; ^de of the page and can be of varying length. The 
^right-hand ^de then produces the desired fprmat for the response; i.e.;> the 
questio^' may' ask tor the i^ft-hand stateipient to be rated as to its relevance 
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and impor^tance to, undergraduate education on a scale from 1 to 7 



9.2 Comments . This s'imple system was quickly written with the available 
resources and equipment. It got the jo^done, quickly and effectively. Also, 

it was written in a general enough form to be used for a multitude of purposes. 

^ . • «. 

10. BUDGET ANALYSIS . > ' . " j 

' - • .... 

' Numerous budget analysis, systems were developed and used^in ^tudies 

for the Vice President for Business Affairs*. However, budget a^aly&is systeids 

wer.e'also developed for Academic Affairs. For example, in planning for 

fiscal^ year 197^- t5,.t]^e Vice President for Academic ^ffairs,' wanted to devise^ 

a system for^ the allocation of incentive. funds among academic -departments. 

f ' m 

A deterministic model was devised. It. consisted of three bagic components: 
research assistants, organized research, »^ fkfeiiaty s^aries. In each 
.component, the basis for calcTilating the amoufit of * incentive fundff to^rbe 
awarded to 'a progr^ was a linear equation based upon {!) sponsored research 
(contract and grant fundT secured) ; (2) ^facility salaries eov^ed by sponsored » 
research; and, (3) student assistant salaries provided by sponsored research. 
The model was run over 50/ times, varying^ the equations andt^xaminirig l^he 
results unMl a strategy was decided and agreed tor ''The system was inter-' ^ ^ 
active and' therefore cordd be' f^pidly'^'^tered and run agaip. ^ ^, 

11. CONCLUSION ■ . _ ; " 

By (l) operating under tough-minded and nornonsenpe. guidelines, and 
(2) utilizing effective tools such as interactive terminals and APL, the. y 
Office of Institntion&l Research has managed to proyide meaningful and 
effective assistemce to the executive management of the institution. * The 
information systems developed, when considered from'i techrij.cal viewpoint, 
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have varied from pedestrian to sophisticated • The type of computerized 
system and (Jegree of sophistication h^ve been dictated .only by what was • 
needed to furnish the necessaiy management information,^ For Institutional 
Resear^ti, this is o.s it should'be. " . ■ ,, ' ^ 
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DISCIPLINE LEVEL 



DISCIPLINE 



STUDENT LEVEL 



MAJOR OF STUDENT 
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Example \- 

(BIOLOGY, Ub, STATISTieS, MAS) = 1.3 SCH. 

i.e., A u^per-division'level'studer.t, majoring in Biology, 
will fcsrefage 1.3 SCH of Stectistics a$ the Masters level. 
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EXAMPLE 2 
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Discipline 



R3M / 
A ^ 



UD 



MAS 



Pfi.D. 



A 


10.5 


< 3 


6.U 


- 


5.5 • 


9.1 


11 




D . 1 


11. U 


0.8 


D - 

• 


6.9 


5.3 . 




E 


12 


10.2 


5- 


A 


3.5 


10. U 


11.8 


B 


9.6 


5.9 


"3.2 


n 


h 1 


0.7 


1.5 


D 


U.6 


8.7 


3.3 


E _ 


n.'7 


2.8 


0.9 


_ei 


2.2 


6.6 


8.*U 


B 


2.3 


5.8 


10 


C 


2.1 


0.1 


11.5 


D 


6.1 




9 


E 


2 


2.7 


• -7.1 


A ' 


9.2 


11.6 


3.h 


B 


♦ 9.9 


1.7 


• 11.3 


C 


ft 0 


10.6 


1^.3 


D 


• . 5*.6 


3.U 


9.8 ^ 


E' 


0.6 


10.1 


6.3 - 



b.a./b.s:- 



MAT 



MAS 



Ph.D. 



PGM 
B 



< 



A 

B 
C 
D 
E 

A 
B 
C 
D 
E 

A 
B 
C 
D 
E 

A 

B' 
C 

•I 



11.9 
8.3 

. 6.8 
2. '6* 

0. .5 

11.1- 

1 

3.9 

1. h 

7 



8.8 
3'. 8 
8.5 
6.5 
10.7 

7.9 

, 5.1 
9.3 
■ 8.r 



2.9 


n 


6.2 


7.2 


0.^ 


1^.9 


. 3.1 


3.6 


•9.5' 

• 


-2.5 


'k.2 


1.1 


' 11.2 


10.8 


■ 1.2 


■U.8 . 




8,6 .- 


. o.k 


■ Ik ■ 


* * * , 

. »- ,10 ,9 •• " 


■■ 5.2 


• ,.".7---' 


9.7. 


•7.6 


' 1.3 ~ 


• "6,7. 


•. 7V5 


^ 1.8 


. 10.3 '. ' 


• 

8h9- " 


■■ 1.6 


. 9.h '■ 


■ "U;7 


•7'.8 


6 ^ - 


• 7.U . 


•7.3 / 


8 


7:7 . 



b.a./b.s. 



MAT 



MAS 



Hi;D... 



Example: 'A Masters level student, majoring in Program A, will average ^ 
2.7 SCH in discipline E at -the Masters- course -level. 
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\1. Introduccion 

\ • ' / 

V The last three decades have witnessed a tremendous explosion in enroll- 

Hients at institutions of higher education. Increased demand, coupled with a 

healthy economy has produced a 600* per cent increase in. undergraduate 

enrollments since 1945, / 

The post World War IJ period has also produced significant increases in 
graduate school enrollment* Between 1945 and 1974, the number of graduate 
students in the United States has doubled.** These changes have been prompt- 
ed By demands in both the public and private sectors for , education beyond a 
baccalaureate degree; with future job advancement and salari^ often contin-^ 
gent upon earning a Master's degree. ^ 

Traditionally, a person holding a baccalaureate degree entered graduate 
school within a vei^ few years after graduation. Furthermore, those indi- 

* 

viduals devoted their, full-time efforts to earning a graduate degree in a 
relatively s\{Qxt period (18 months for a Master's degree; three and a half 
years for the Doctorate). Admissions procedures and academic policies were, 
-^geared to the mode of • a full-time, on-campus, graduate student. 

The last decade has ushered in a new era in graduate education, and the 
mode of advanced degree earning has changed. Faced by increased employment 
requirements to further their education, but stymied by family responsibi- 
lities and communal ties, a growing numbel: of individuals have been reluctant 
to "pull up roots*' and make a full-time commitment in pursuit of a graduate 
education.. Their^clarion call has been for locally produced part-time 

*The Carnegie Commission on Higher Education, Hew Students and New Places , 
McGraw-Hii; Book Co., New Yor^, October, 1971, p» 129* 

**Ibid. , p. 131. 
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graduate -eaucational opportunities, 

Cogailzant of these changing needs and demands, Virginia's Land Grant 
tJniversiriy has responded to its educational misiion by offering off-can5)us 
graduate degree programs throughout the Commonwealth. From a modest b^inning • 

• of 200 students in the micf 1960* s, off-campus enrollment now e^eeds 2,000 
active gradixate stuti^nts. In aJJiLion to oftering degree prograae-iar^uch 
xonc^trated population aAas as Reston, Richmond and Dahlgren, courses are 
.also offered. at virtually any map coordinate displaying sufficient potential 
d^pand to. assure a viable program. Virginia 'Tech currently offers between 100 
and 150 off-campus clsisses each qiiarter. 

" • Administrative problems are magnified by the fact that personal and 
professional demands placed on part-Linie graduate students make it diffj.cult 
' for them to maintain continuous registration. Consequently, several quarters 
may be skipped between enrollments.' The Graduate School and the Registrar's 
Office are charged with the . responsibility of maintaining a complete academic 
record of all active and ina6tive students. 

During 1971, two clerks worked on a full-time basis to support the 
,adaii«loM.ation of off-campus programs. They maintained files for 3500 active 
and inactive students. All applications and registrations were hand processed. 
Roll sheets, grade sheets and grade reports were, typewritten. It became 

. increasingly obvioixs that a computerized off-campus student record system was 
necessary to copfe with the deluge of paper. Thus, in September of 1972, a 
tape oriented system was installed to assist the record keeping process. This 
marked the beginning of the computetftzation of off-campus graduate student 
records. , - 
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2. Policy 

Virginia Tech has attempted to respond to the increased demand for part- 
time graduate studies by adopting a liberal admissions policy for off-campus 
gradixate programs. Students are permitted to enroll iii one class prior* to 
beings formerly accepted to the Gradixate School • This permissiveness is 
contingent upon the student initiating and completing the admissions process 
within the six weeks. 
' 3. Current Prospective 

The Graduate School administrative record keeping requirements have 
produced a complex set of data processing specifications. During the last 
fiv^ years, the off-campus program has grown from Z500 students C^OO active) 
to 7000 students (2Q00 active). Furthermore, record, size requirements have 
^ tripled from 300 data bytes to 1000 bytes per student to accomodate a complete 
acadeisic and demo graphic file. 

As noted above a student may actfually begin graduate studies prior to 
being officially accented. Without a formal application, a student's regis- 
tration form generates a very inadeqixate data record. Recognizing this, the 
registration form was modified in 1972 to parallel an admissions application/ 

From the population of all registrations received that Fall quarter, a tape 

» 

f^lc was constructed to generate a computerized graduate student data^base. 
A tape system, which had been in service for on-campus record^ since 1965, was 
adopted to serve the off*-campu^^rJeeds. • . ' 

A subsequent modification of the registration form.by the Accounting 
Offiqe resulted in a document void of demographic data elements. This pre- 
cipitated a problem with the student who decided to attend class, but never 
inlXiated tne admission application process. No tape record was constructed 
for persons in this situation, and for all practical purposes, their atten-. 
dance was unknown. 
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3.1 Admissions ^ . 

A flexible admissions policy requires responsive administrative procedures. 
An initial course registration form may or ^ay^not he accon^anied by a com- 
pleted application, transcripts and letters of recommendation. If all materials 
are received, a decision can be made to accept or reject the applicant. In the 
j^vent that some materials are outstanding, the student must be advised that an' 
application and/or other credentials are required and the file must be complete 
within six weeks so that ,a decision regarding admission can be made prior to 
the«end of the quarter. 

Applicants who do not submit a complete set of credentials within the 
prescribed time limit are advised that they will be graded on a pass-fail 
basis and the »ingie course in which they are currentfy enrolled may not be 
used for graduate degree credit. Admission to graduate school is rejected for 
failure to fxilfillthe requirements for a complete application. 

Rejected applicants are advised that they may not register in subsequent 
quarters. Despite being so notifiecT, some students persist in attempting to ^ 
register for additional cours^ft* The auministration of ^ the^ Graduate School 
must have the capability of monitoring a student's status so that those who 
were rejected for academic reasons, oi for failure to -provide the required 
' credentials, will have' future registrations voided. 

Once admission status has been determined, the decision is communicated 
to the applicant in writing. Currently, letters to rejected and accepted 
applicants are typewritten. Productivity consideratiotis dictate automation, 

while public relations require" a personalized conmunique. Specifications have 

ft 

been developed for a subsystem to transmit* address data to a Mag-Card Selectric 
Tjrpewriter in the Graduate Office via a telephone link from the Computing 
Cent.fer. Name, address, and degree information will be transmitted and recorded 

* 228 - - 



on k magnetic card whjLch is then processed by an MCST (Hagnetic-Card II) . 
Accepted and rejected applicants will be processed in ba^i^es. Each applicant 
1^11 receive a personalized letter of acceptance or rej#tion generated as a 
, result of the telephone interfetce between the Computing Center and the Graduate 
Office. ' 



3.2 Admission Status Reporting : 

The magnetic tape recptd did not jJermit instantaneous retrieval, updating, 

'% ' * . / 

and reporting of applicant admi^&i^ii^s status^ This produced administrative 
problems because it was difficult to ray,lew and communicate this information 
when needed . ^ * ' . - 

In April, 1974,. the o£f*-campus ta|^ file was loaded into an on-line IMS- 
(Information Management Sy&tem^ reco^ .System then in use for on-campus 
students. This on-Hnp Interaction. Remitted in8t5:itaneous retrieval, veri- 
fication and updatingof a students *s status. \/ 

A computer program was written to process admissipn records and construct 
an Admissions Status Report. This listing includes ^ ajiplicant's name and 
address, academic data related to the undergraduate major field of study, 
institution where the bachelor *s degree was, earned, d^te undergraduate -degree , 
was conferred, undergraduate grade point 'average, graduate degree, graduat^e 
major, graduate grade point average, graduate institiftion, date graduate 
degree was conferred, and admissions test. scores. For management purposes the 
status reports aira org^ized according to campus location^ within the 

tCommonwealth. - * *^ 

* ' * ^ i I ' 

Applicants ^.aza^or ted alphabetically, by departm^ts. Each report is 
divided into four parts: 
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applicants pending 
applicants accepted 
^ applicants withdrawn 

applicants rejected 

Departments receive applicant status reports semi-monthly. 

3;2.1 Pending Report 

The objective of the Pending Report is to display all graduate appli- 
cants whose admissions are pending review. This report serves as a vital 
communications link between the Gradixate School and the Departmental Admis- 
tfions Conaaittee. It notes the reasons why an applicant's credentials are 
incomplete (e.g., missing ttanscripts or letters of recommendation). It also 
permits a department to concentrate its recruiting efforts on highly qualified 
students by flagging those with outstanding* credentials. Enough information 
is available to permit personal follow-up and avoid the risk of losing a good 
Student because one letter of recomnendation has been inadvertently delayed. 

3.2.2 Accepted ♦ Rejected and Withdrawn Reports 

These parts of the applicant status report are in the same format as the 
applicant pending section. Control breaks, by campus location arid department, 
arc also the same for all parts of the applicant status report. 

The Withdrayn Report li&ts the names of applicants who have withdrawn 
their application for admission. 

3.3 Registration 4^. 

Prior to 1972, it was difficult to manually place the right student into 
the right class. Th? advent of the tape system significantly increased the , 
reliabiJlty of this procdss. 

o ' 230 
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Nonetheless, many problems continued to exist. The registration * 

form was quite archaic* Although it satisfied the needs of the Accounting 'ZZ 

Off ice,. it did not provide sufficient data to identify students who were 7, ; 

not formerly accepted,. Persons in this category were a^ccounted for only . # 

when the' professor brought it to the attention of the Graduate Scliool, -r' / 

The registration form was 5''^°equently re-designed to include the student's ..V 

name, address, social security number, and telephone number. That is, 7 

enough demographic information was included €0 identify the student and • _~~ I 

make further communications possible. ^^LJ 

3.4 Roll Sheets ' 

Institutional requirements set a high priority on recording the _^ : 

registration of ^ all students via an accurate class roll. It is Imperative 

/ * ■ . - 

that class rpUs include all students vho have paid their fees and are*^ 
attending class. • " 

The revised registration form is used to create a skeleton student 
record 1 The skeleton record makes it possible to identify Lhe student 
and assign him an admission status for inclusion on class rolls. This 
annotation may be coitanmicated by the professor so that students who are 
walk-ins and have not made formal application to graduate school may 
take whatever remedial steps are necessary to complete the application. 

' 3.5 Grade Sheets 

. During the final week of the academic quarter, the Registrar's 
Office produces a grade sheet for each off-can^us course. A grade sheet j ^' 



is very similar to a class roll, except that it contains the names of 
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all persons wbo have completed the course an^ are eligible to receive a* , 
grade. : * ' 

Prior to September, 1972, grade sheets were hanT^processedT Between 
the preparation, of^ class rolls and grade sheets, ^a tremendous amount of 
clerical effort was required to produce an accurate grade document. It 
was. necessary to Process all late resienations, drops, adds, and student 
status changes against the most recent class roll. The modified tape 
system has materially aided the production of accurate grade sheets^ 
^Future plans include to on-line grade system ^expected to be available 
before ^anu^ary, 1976. \^ 

3.6 Grade Reports ' 

At. the end of. each 'academic quarter student grade reports are 

printed. It is desirable to have all grade sheets returned from the '* 

class professor before student grade reports are generated. If seVetral _ 

grade sheets are returned late, it becomes necessary to generate, a 

second grade report for students who completed the course represented on 

•Lhe iate grade sheet. ^ ^ 

Applicants who have not been admitted to the Graduate School (rejected 

or pending) are not awarded the letter grade assigned by tne professor. 

University .policy requires that grade reports of thes^e students disiSlay 

. a pass or fail grade, whichever is a^ropriate, ' and a me«eage explaining 

why the letter grade was not reported. These students are notified that 

thfl course will not carry graduate credit and any future ^course Requests 

will not be accepted by the registrar. 

Prior to Septeiuber, 1972, all of f-camptis grade reports had to be 
g 

typewritten. Needless to ^ay, this required a tremendous amount of 
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intensive clerical effort to insure complete accuracy. The modified ' * ' 
taps system has significantly enhanced the efficiency and efficacy of- ^ 
generating grade reports. ' ' * . 

# 

f 

4. Plan of Study 

Graduate School policy requires that all graduate' students submit a 
plan of study for approval. Plans of study serve as a contract ^b^tweett 
the student and thfe University to indicate how each individual anticipates 
satisfying his advanced degree requirements. Each plan of study is 
reviewed to be sure that it satisfies all university requirements regarding 
minimum and maximum number of course hoifrs at^ several levels, when and *^ 
where ^courses will be completed, number of hours to be transferred frpm 
other institutions, and minimum number of hours taught by full-time 
Virginia Tedh faculty. Plans of study are monitored to maintain academic 
integrity. 

In the future, plans of study will be entered on the ,computer via 
an on-line^ IBM 3270 terminal. The computer will revie^^sOhese pla^is to 
determine if specific degree requirements are. satisfied. 
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4.1 Management U^s 

A computerized plan of study has another important advantage. It 

0 

.*can aid in pr^edicting the demand for future courses, by location, * 
throughout the Commonwealth. Demand 3.S a function of all students* degree 
requirements, minus completed courses. If plans of study are accutd^^ely 
maintained, management reporta can be generated to ai'^d in the allocation 
of faculty resources, classroom facilities, library support, and to 
assure students that courses will be available when and where needed 
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far enough in advance to produce sound academic and institutional planning. 

« The aforementioned considerations .produce significant logistical . 
problems. University policy requires that at least 50% of all course 
work taken by an .off-campus graduate student be taught by full-time'^ 
Virginia Tech .faculty/ In order to satisfy this requirement, department 
heads'.mu^Ffe^ allocate faculty resources to meet their on-campus and , of f- 
cafapns .inetructional commitments. Logistical problems are also encountered 

in making travel Arrangements between Blacksburg and the ,off*-campus 

-■> 

locations. Sometimes this distance Is in excess of 250 miles and several 
locations are not readily accessible by air, travel. . 

Some of the of f~campus course^ cannot be supported by on-campus ' 
, professors. Therefoire, it becomes necessary to screen and recruit qualified 
adjunct faculty to ^f ill the void. ^. .r., 

^ A viable -gi^aduate program requites access to adequate library 
'facilities. To supplement locally available reference' materials, the 
Virginia Tkch library responds, to faculty requests by shipping books and 
journals t6 the off-campus locations.-" 

The problem of identifying suitable off-campus classroom facilities 
in appropriate locations ie a never ending task. The most difficult task 
*is finding classroom tspace in the more^ remote areas of the state. 
Class§s have met in firehouses, church basements, high school rooms, 
etc.^ 

Solving these dynamic logistical management problems can be aided 
by t^e use of the cQjnputer and forecasting course demand based on plana 
pf 9tudy. 
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A computerized graduate plaa of study has several additional advantages. 
Shortly a|ter the termination of each academic qu^ter^ the program 1)f 
study data base may be Interfaced with the current grade system to 
produce a hard copy Itinerary contal^ing all up-to-date revisions and 
•grades earned. Ji copy of the program of study will be sent to the 
B^udent in the form of a progress report* Copies will also be sent to 
the student's faculty advisor and the Dean of the Graduate Schopl dn an 



endeavor to monitor acceptable academic progress. * Students who are in 



academic |ifficulty can be identif||||j^ early and given proper counseling* 
Thus, thede reports serve a vital rble in the effective administration 



pf alX gr^uate programs. 



5\ Syateins Development 



• In. 1971, the Graduate Office received the first module of' the new, 
on-line IMS student record system* " An admissions module was implemented 
employing an IBM 2260 video display terminal fpr on-line data entry and 
retrieval (later superseded by two IBM 3270*s now in use)* A group of 
reports were developed that depended on admissions .data developed in on- 
•line mode. The package included ^he following major reports: 

1. * Applicant Stati^ - pending, accepted, rejected; 

2. Curriculum,' department and cpllege enrollment reports; 

3. ^ State Council - summary of graduate students enrolled, by 
City and County; , " . ^ 

^ 4* Incomplete grade report; , ' 

5* Graduate Student AcadepCLc Statu^ Report ,^ t , 
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Actixal offrcampus con5)uter systema developnieat was begim during the 
Summer of 1972 when the on-campus tradj/Ltlonal Basi'c, Student Record tape 
system was employed to processi off-campus gradtiate student records, ^ 
Although all hand processing operations wpre virtiiallx eliminated, a 
nxunber of problems were encountered attempting to apply *a sysrem designed 
for an on-campus environment to process off-campus graduate student 
recotds. Many problems originated from the unique policy that permitted" 
an off -campus student to enter a class prior to being a^iitt^d to the, 
* Graduate School coupled with an injadeqtiate registration form that did ^ , 
not contain sufficient demographic data to identify the student and . 
permit. .administrative follow-up » . . * , , 

In April df 19^3, the* Graduate School hired a Systems Analyst . to J - 



jrevamp the tape system ai;^d to assist in the design and in5)lementation of 
the "new on-line ;nodules. His major responsibility was to address himself 
to the unique requirements of the off-campus record keeping process. 

During Aprils 1974, the off-campus student record; tape was loaded 

• / , ' ' ' - 

into the on-line student data base. A campus location code was assigned 
.to each off-campus record for identification purposes,^ This narked the. 
beginning of on-line student recopd processing. Status reports were 
then available for offrcampus applicants. 

Application data Were entered directly from the Graduate^ Office 
using an IBM 3270 terminal thereby eliniinating the need foV coding and 
keypunching and the^ associated inaccuracies. A systems interface was 
designed ^' programmed and implen^nted to bridge the gap between the on- 
line admissions module and the roll and grade reporting tape system. 

The tape system is still employed to generate class rolls, ^grade sheets 

• J, 

and administrative reports,. 
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6. Futu re Plans 

development pf the student record system is by no means completp- 
Future' plans include the implementation^ of a number of additional modules. 

6.1 * Optically Scanned Course Requests '. . 

An on-line re^stration -system has been implemented for on-campus 

student record processing. There are ,two .methods of data input. One, 

an optically scanned course request form is batch processed and then nin 

through a plass scheduling algorithm. Two, cl^s drops and adds are 

proce&^ed via a 3270 on-line terminal. 
* . 

, Within 'the next yeat, all off-campus registrations will be processed 
in the same fashion. A pre-printed optically scannable form has been 
designed to fit a standard business size envelope. This form will be 
mailed to ail active off-campus students. Completed forms will be 
returned to^'Blacksburg for computer batch processing. 

Fees liay be returned by, mail and must be paid at least two weeks 
prior to the beginning of the quai^^r.' Students who fail to meet the 
payn^nt dea41|5tf vcLli have their course registrations purged from the . . 
system. \ ^ , ' 

,6.2 On-Line Grade Processing ^ 

During ^ the Winter, of *1975, an on-line grade system will be installed 
■> •* " * » 

on-campust Machine readable grade sheet's will be prepared for all 

classes. Grade sheets w^ll then be optically processed Miitllar to the 

... . ' * ' 

* course* requests, drades will be appended to each student *s academic 

rfeQord^. A grade report will "be* printed' summarizing each student's 
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performance for the current quarter as well as accumulated grade point 
average. This system will also procoss off-campus };rado.s. 

.,6.3 Dial-Up Terminals 

Several areas in the Stat^ of Virginia have high concentrations of 
potential graduate studenta, particularly in the metropolitan regions ^f 
IflfaShington, D.C/, Richmond, and Norfolk. Tlie Graduate School, in conjunctioA 
vrlth the Virginia Tech Computing Center, ^s studying the feasibility of 
using portable dial-up computer terminals at, remote locations during 
.registration. This, will aid faculty advisors by permitting them tx) 
review curren^t academic records for use in student consultation. 

<v 

6.4 Inactive Records . - . ^ 

A classical problem with all on-line systems is the high cost of; 

storing inactive records. Based on past experience, approximately three 

out of every four off-campus records are identified, as inactive students. 

That is, three out of every four records are not referred to ,or updated 

J at least once each quarter. Because the population of active off-campus 
. 

graduate students is very dynamic, inactive records must be removed from 
and recalled to the on-line environment as efficiently as possible*/ 
Magnetic tapes are used for off-line stor^^ purposes. 

I * ■ • . • 

Students who have not registered format least one course duriny. the 
currerft academic year will have their records removed from the on-line* 
system. An on-line to off-line migration report is created to serve as 
an audit trail for inactive student records. This report contains 
sufficient' information to locate inactive records should the need arise. . 
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6.5 Ori-Campus Remote Data Retrieval 



At present, each of the seven colleges has at least one IBM 3270 
video display terminal. Keyed messages from these terminals are trans- 
mitted to an IBM 370/168 computer. ' Student records may be transmitted 
back to the college terminals on a need *to know basis. No updating is 
performed at the college terminal^^except^ for registration transactions 
related to dropping or adding courses. 

The use oj/remote termihals requires a reliable security system. 
Data security within Virginia Tech IMS information system is pf two 

, types. First, unique transaction codes and/or passwords are associated 
with each terminal. This is accomplished within the* IMS software. 
Second, security may be controlled by the applications program. That 
is, not permitting pne college and/or departmemt to retrieve information 
for students .enrolled in another college- or department because rOf 

< restrictions on a need to know basis. Once the data retrieval systems , 

achieve the anticipated level of sophistication, on-line review of off- 

.campus records will, significantly enhance the efficacy of student advising. . 

* 

7. Closing Statement 

The most difficult Problem associated with the develQprment of the 
on-line student record system at Virginia Tech is maintaining a constant 
awareness. of the unique data processing requirements of the off-campub 
environment,. Our ultimate objective is to produce one record system capable' 
of handling all students, regardless of type. This -requires in-depth* analysis 
and total understanding regarding the three distinct populations of students: 
undergraduates t on-campus ^ncl off -campus graxliiates. 
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Systems development is an iateractlve and iterative process. In our 
view, successful development effort can not be accomplished without constant 
communi-cations between the user and the developer. The dynamics of a complex 
institution make it impossible to cast the total systems development specif ica-- 
tions in bronze, a priori. We have chosen a modular development, with the 
constant view toward modifying the system to satisfy ever c;tanging student 
record keeping requirements. We have attempted to maintain a constant vigilance 
and an awareness of new ideas and changing techinology to guarantee ^ximum 
productivity from the allocation of scarce resources in the production and 

maintenance of on-line computer systems at Virginia Tech. 

* « 

8. Corollary , ' ' 

One of the major lessons to be learned from our experience is the critical 
need to properly interface the data processing^quirements of the administra- 
tor and the technical expei^tise of the Systems Analyst. .Typically, the busy 
administrator has a. reasonably but not necessarily completely defined set of 
f needs, and only a nodding acquaintance with data processing. ^The analysX 
p&sesses the technical competence, biit lacks first hand knowledge of unique^ 
admini:>trative problems and requirements. We believe that casual periodic 
communications between ad^ministrator and developer may not produce a satisfac- 
tory system capable of encompassing the needs of a complex dynamic environment. 
What is needed, in our opinion, is a daily, shirtsleeve working arrangement, 
that meets the needs ol the user, rather than -simply satisfies the es9teric 
self -satisfying professional requirements of the producer, I 
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THE REGGIE SYSTEM 
Frederick A. Kundell, Associate Ac^»^'^-njic Dean 
Salisbury State College 
Salisjjury, Maryland 21801 

* 

Registration, because of the conplex and capacious amount of information 
v^hich must be stored, sorted, arid analyzed, .has been a prime target for com- 
puterization. The REGGI^ system of programs was designed to facilitate the 
registration process by minimizing the manual effort and time involved while 
maintaining the decision making potential. The system is composed of programs 
which were designed to aid the registrar's office from the preparation of a 
conflict free course schedule to, wheA finished, the analysis of final grades. 
The system includes a sectioning algorithm which the author feels is superior 
both in run-time and accuracy to any other in existence. Finally, both the . 
input and output were designed to be easily understood by people who do not 
have a data processing background. J/ 

1 . PNTRODUCTION 

Registration is a necessary component in and evil of our present collegiate 
educational system. Its goal is the documented assignment of students to 
courses in accordance with the conditions imposed by the physical -plant and 
academic'community. The complexity of this procedure varies with the size *of 
the student body and the procedure employed. 

The REGGIE system of programs was designed to facilitate the registration ^ 
process by minimizing the manual effort and time involved while maintaining 
the decisio;! nXaking potential. The remainder of this paper will be directed 
toward an overview of the sysf em. ^ 

2. SYSTEM CONFIGURATION* 

The REGGIE system is conposed of a set of nucleus subroutines, which remain 

* Based on X-RAY 67, PROGRAM SYSTEM FOR X-RAY CRYSTALLOGRAPHY, J. M. Stewart, 
F. A. Kundell, et al. Technical Rej^rt 67-58, Con5)uter "Science Center, Uni- 
-> versity'of Maryland • ' 



Vol. II ' ■ - . • •,-243' 

in core at all times, plus the system programs, which reside as overlays. - 

J 

The nucleus subroutines handle all input-output and act as a system monitor. 
This design yiel'ds a very flexible system in which the program sequence is 
controlled by the input card stream. While the programs ivere written to work 
• as an integrated system, they can easily be separated fo^ independent use. 
2 1 CODING . The system is writter^ in Univac 1100 series^PORTRAN V. Each sub- 
routine is headed with a brief introduction which states ors purpose and 
position in the systenu lii addition, the code is broken^d^<) logical blocks. 
Each of these blocks is introduced with a fairly con5)lete 'description, mthin 
the blocks each logical operation^ is headed with an explanatory comm.ent 
(APPENDIX I). » 'r-^ 

3. SCHEDULE -FILE ^FORMAT . • • -.1 ' 

• * 

The system, as. it .is now constituted, utilizes a sequential data file 
composed of ten physical records. Each physical record is congposed of from 
one to 'N' logical rec ords. The size^ of the logical record is set in accord- ^ 

> 

ance with the software specifications of the machine (eg.\pjv-the Univac 1106 
there are 255 unable words per file record).^ The ten physical records are^ 
assigned as follows: 

4 . 

1. File history and key record ' , 

2. Instructor record 

3. Room record 

4. Student information record 

5. Course requesj:, - course assignment record 

6. Course scliedule record ^' 

7. Abbreviated course schedule record. 

8. Grade roster record J'^^ 

9. Not assigned yj * 
10. Acts as a system end of file ^.f^ 

^ ^* ^ ^^jf 

.Physical record one contains^ tHe frTe^RTsfoi^^' and'Yey. the file can only be 

read by the systen^ if a duplicate key is submitted at the beginning of the job 

stream. The first file access causes_th.e^J^Xe.,Jd5XQjry_to be prjmted (ABPENDIX II, 

San5)le Listing 2)* ^ ; * ' 

' 243 ' ■ 
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Additional physical records may easily bemadded as the need arises • Fur- . 
thermore, by modifying the nucleus routines^ the desired information could be 
' retrieved randomly ' from a number 6f different files. A dump of the 'REGGIE 
TEST DECK' schedule files appears in APPENDIX IV, 
4. MASTER COURSE SCHEDULE PREPARATION 

A well-planned master course schedule can vastly sicplify subsequent opera- 
tions. A number of programs have been included in the REGGIE system to facili- 
tate this process. It is generally recognized t^iat the manual maintenance or 
parallel files, is difficult, if ;iot iii5)ossib^e. Consequently, the REGGIE 
system was designed to read the same course schedule as is distributed to the 
students- In fact, the system pr|pares* the master listing for publication 
(APPENDIX II, Sample Listings 3 and 4). This schedule, having been thoroughly 
checked by the system, has a ijinimum of clerical and s'cheduling errors. 
4.1 THE LOAD-SCHEDULE PROGRAM . The schedule file is initialized via the 
LOAD-SCHEDULE program. It creates ph)fsicaA records one, two, three, six and 
seven. The . remaining records are initialized as 'd^nmy' records. The first 

deck read is the instructor deck. This deck contains one. card per instructor 

* ■ * ♦ . 

and is normally loaded in alphabetic order (APPE1?DIX II,San|)le Listing 1). 

( ■ • ' 

The second deck contains room information. .The sj^stem utilizes the master room 

deck prescribed ^ the Boatd of Trustees of the Maryland State Colleges*. It . 
should be noted that both- the instructor and room listings have been welj 
received and utilfe^ on campus (APPENDIX II, Sample Listings 5 and 6). ' 

The master coarse schedule is loaded in two steps. The first, the LAB-LIM 
deck, contains abbreviated course titles, used in the preparation of the 
permanent record (LABEL), the class limit and type, the sectioning group to 
, . which the section belongs (blank if it is to be assigned by the system), and 

* A variation of the fonnat listed in "Higher Education Facilities Classifica- 
tion and Inventory Procedures Manual^' published by the Maryland Council for 
Higher , Education . 
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whether the course is being taught for a set fee (part-time or overload) . The | 
second deck contains the course schedule in a format similar'to the published - 

forri. • • -V 

The LOAD-SCHEDULE program checks the submitted course schedule to make sure >^ 
that the information is con^jlete. The items checked are the course numbet, 
title, semester hours credit, meeting time, abbreviated title (label), and the ?g 
limit. In -addition, it ch^cs the assigned room against the master roomr list f- 
and the- instructor against the instructor list. If an error is detected, it 
is noted to the right of the master schedule listing' (APP.ENDIX II, Sample ^r^- 
Listing 7), Subsequently, the class limit is checked against the room capacity.; 
If the capacity is exceeded, this fact is noted on the LAB-LIM listing 'c^' 
(APPENDIX II, Sai!?)le Listing 8>. >^ 

A^the course schedule is 'being read, a condensed schedule is devkoped in 
core. This schedule'contains abbreviated instructor and room informati^ plus ' -J- 
for each course, the department abbreviation, the course number, the clasB 
liVtr, a blank woird for enrollment, the group symbol for sectioning, the sWs- -r.^ 
ter houcrs credit, and pointers to the instructor, room and time information. 

The c?bck hours, as they appear in the schedule of classes, are, trans- 
lated into a readily usable form by. the LOAD-SCHEDULE program. The stored 
time is eon5)osed of three segments of one, four^and three decimal' positions 

respectively. ' 
i 

> .X / XXXX / XXX 

Segment 1 The End Flag 

This character is zero for all but the last meeting time of 
a section. It is unity for the last. 

Segment 2 The Position Pointer 

The positioS pointer indicates the starting time of the 'class 
' meeting. The week, Monday through Saturday, from 6AM to midnight 
■ ' is broken up into- five-minute intervals as follows: 
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A position pointer for Monday at 6AM would be 0001/ One for 
Thursday at 6:35AM would be 0046. 



Segment 3 The Duration Counter 



es 



The duration-counter is the number of . five-minute intervals 
in a class meting. 

MWF 6 * ^ 00001010, 00003010, 10005010 
•TR 6:15-6:3^^*^0020004, 10022004 



The following are exam^^ of acceptable time natation: * ' 

MWF 9 (50 min. cl^^ T 5:00-6PM 

• S 9:00-11:45 S 9-11:45 

- MWF 5'6:15 PM •^^ir TR 1:30-2:45 

-^DAILY 9 ^ DAinY^10:30-ll:45 - 

MWRF, 10 .1^' MTWRF 1- 

TBS • ~ TBA 

The condensed schedule!is loaded onto physical record seven as a core dump. 

This record is used byjiumerous. programs in the system. 

It, should be noted\ithat the LOAD-SCHEDULE p)rogram can be run in an update " 

mode. In this mode, ^Jter entire decks can be replaced, or they^can be cor- 

•rected using the DELEJ& and/or INSERT card options . , ^ 

4.2 THE ROOM-CHK AND PROF-CHK PROGRAMS . The ROOM-CHK progifam was designed, 

to analyze classroom utilization. It prepares a room sch'^dule for each room 

referred to in the master course schedule* Each class is indicated in its 

proper time slot with the course nuinber, instructor, and class limit noted. 

After the student course requests have been' loaded, the class limit can be 

replaced by the actual number" of requests for the given course. If conflicts 
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*. occur, they are noted ard the conflicting courses indicated to tjie right of 
the time grid. All classes assigned to the given room are considered; If 
there, was .a time error or if the course time^was not specified (TBS or TBA) , 
^ this, information is noted. In addition, the room utilization is calculated 
and" printed. - - 

^ ' ' ^The ROOM-CHK program can be used to list all^ rooms referred to in the 
. master course schedule, those in a given building^ specific rooms, or a ra^ge 

of rooms. In. addition, if specified, it^will only list those rooms iir which : 
conflict occurs (APPENDIX II, Sanq)le Listings 10 through 13). 

The PROF-CHK program is 'conqpa^able to ROOM-CHK (APPENDIX II, Sample- List- ^ 
^ ings 14 and 15). It prepares the schedule for ^ath instructor ^listed in the 
master course schedule. The user also have the option to list sxihedule^ for 
specific instructors oi a range of instructors. Again "tlie PROF-CHK program can ^ 
be run in the conflict miode. , - ' ^ 

During master course schedule preparation, we normally rxan the LOAD- 
SCHEDULE program, in either the a priori or update mode,>l)lus a con5)lete , 
ROOM-CHK and PROF-CHK, listing only. those instructors who have conflicts. 
•Using this proceduij^ we can^develop a conflict-fre^ schedule in a matter of 
hours. Normally we devote acouple,oi£ ^j^yg ^j^e process. 

At the beginning of each senfester a full ROOM-CHK and PRQF-CHK listing is 
prepared and distributed to all adminstrative and departmental offices oh cam- 
pus. ,fhus anyone who wishes to contact an instructor has his schedule avail- * 
able. The ROOM-CHK lining is use4.extensiT?eiy by the maintenance and instruc- 
tional resources departments. It i^Hbmportanf for them to know when^ classrooms are 
free for cleaning, repair, or for setting up audio-visual equipment. 

It Would be a savings of both time and paper if the ROOM-CHK 'and PROF-CHK 
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programs could be run on-line using a CRT.. We plan to make this change as 
soon .as the hardware becomes available on cairpus. . / . 
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. - 5,. REGISTRATION ' * / ^ / ' • . ' * 

The primary reason for the development of the/REGGIE system was the test- 

^ ' - . * , / 

ing of a new sectioning algorthm*. While the schedule preparation programs 

have become extremely i^ortant in their pwn right, their development was 

*' ! * ' 

dictated by the need for physical record se^en, the Qondensed course schedule. 

In this .section, the j.n5)lementation of "An Algorithm For Conputer Registration" 

shall bB discu^d along with the results of the Salisbury' State Collegp fall 

registration. 

5.1 THE LOAD -MImE PROGRAM > The LOAD-NAME program loads student information 
injo physical record four of the schedule^ file (APPENDIX III, Sample Listing 1). 
At the j)resent time we only load the student name arid social security number. 
This, record should be e}q)anded to include other useful information such as the 

0 major, student classification, etc* The major is of particular ijnportance if 
a ca:'oss-over stujdy p'rogram is-/to be added to the sys^m.'^ . ^' - 

Since alphabetic student listings are required throughout the system, the, 
student names are loaded into physical record four in alphabetic order. When 
read outi by other programs, an alpha sequence numb^ is 'appended to the record. ^ 
In most cases, thV student nairfe social security humber cards are^^aded in 

alphabetic order. For this reason a sort algorithm was ^sired which could 

' ^ . ^ ^ » * • "* 

recognize this fact and :thus avoid a time-consuming and costly sor^. While, the, 

' • ■ A- J 

' algorithm developed has probably been used countless times before, jio one xri^ 
our. shop had run across it. For this reason, I haye added a bri^f , description^ 
in APPENDIX VI.* . • ' / 

5.2 THE TALLY PROGRAM > The initial phase of the sectioning algorithm is a 
tally of c||rse*requests. , This, tally is stored in physical record seven and 
is used in dev^oping the status indicator in the sectioning program. In 



* Frederick A. Kundell, An Algorithm For Computer Registration, College send 
University, Vol. 48, Winter, 197^, pp, 87-89. * 
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addition to this, the TALLY program serves several other critical functions in - 

the system, - ^ ' ^ 

First, tlje TALLY program builds the student course request record, phys'ical 
record five. The program is "designed to run either in an a priori mode from ^ 
* cards or from a previously prepared data file, or both. 

Second, the program checks the student requests against the student infor-. 
mation record,^ physical recprd' four/ If present, the student's name and the- t 
alph|i sequence number if appended to.' the course requests. If not present, tne 
name is set to blanks and 'th^;:|[ipha sequence number set to. zdro. In addition, 
an enfry is made in the TALLt%^gnosiic report) (APPENDIX III, Sarap-le Listing 2). 

Third, )the student course.^^^ijtest4i:|r^ checked against the master course 
schedule. If the course, or^iior4(5li being offered, the fact is noted 
i in the diagnostic report (APPENlix; HX^^ample Listing 2) • 

Finally, the program lists tfce studeBt requests bysection and student 

„ * ^' ^ - 

\ classification. This listing ffe^examljied with the department chairman to see 
if mgdifications to the master course schedule Jre required (APPENDIX III^ 
Sample Listing 3). A copy of the TALLY listing is also sent to the^^ college 
book store. 'I ^ ' 

two additional reports are generated by the TALLY program. The first is 
an analysis by course and srectioning group (APPENDIX III, Sample Listing) ^ 
The second repqrt gives the overall" TALLY statistics (APPENDIX III, Sample 
Listing. 5). 

' 5, ^ THE SECTIONING PROGRAM. / The sectioning program b^gina by reading physical 
record seven, the Condensed schedule. This schedule now contains the number 
of course requests as calculated by TALLY. ' k status indicator for each' section 
ip the schedule is calculated by subtracting the class limit from the number 
of student requests. If. the status indicator is zero, the class if full 
(t^.e., all available seats have been taken). A negative status indicator is 

^ - 249 
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numerically equivalent to .th^ number of unsubscribed seats iu -the section and 
a; positive status indicator is ntHneHcally equivalent to the over subscription. 
Subs(Bquently, the status indicators for all sections in a given course and 
group are summfed. This number is referred to as the course status indicator 
y or CSI.. The CSI has the same numerical significance as the status^ injdicator, 

but 'relative to/the entire course, "or group, within the course . 

> 

The stjident course records are now ifead from physical record five. The | 
status indicator for each requested sec^tion is first checked. If it is zero 
or, negjative, the student is enrolled in the section. If it is positive, the 
section is oversubscribed. In such a, case, an alternative se.ction is sought, 
.if the CSI is not positive. If the CSI is positive, ,the course is oversubscribed 
and the studerit is not enrolled in the course. I" such. a case both the status 
indicator and CSI are decreased by one. If the ^^^^J^ negative, an 

alternative section is sought. The alternative section must have a negative 
status indicator and be con^jatible with the remainder of the student's schedule. 
If an alternative section is found, the student is enrolled, in it and its ' ^ 
status indicator is increased by one. At the same time, the status indic^or 
of the requested section must be decreased by one. If an alternative section 
is not found, the student is tentatively enrolled in the requested section. 

After all student requests* have been considered, the request record is * 
copied onto the new schedule file. Prior to the actual copying, all status 
indicators are checked. Status* indicators which are still positive .are noted. 
* In the copying phase the course assignments are scanned for oversubscrijbed 
sections. When found, the student is dt6pped from the section and the*status 
indicator decreased by one. When all status indicators become zero or nega- 
. tive, the remaining .course assignments are simply copied across. 

The SECTION program prepares a statistical page as its sole output 

" (APRENDIX III, Sample Listing 6). In normal operations the SECTION run is 

O - . • c 

ERXC followed by a-second TALLY run' (APPENDIX III, Sample Listing 7). - 
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V 5,4 THE SCHEDULE PROGRAM , Three programs play a primary vole in the initial 
registration processV The first two, TALLY and SECTION, have already been 
considered- The last-^s the student schedule preparation program ^'Schedule" 
(APPENDIX III, Saxsple Listing «)• The schedule card contains two message 
fields. The first is printed on all schedule cards. The second is printed 
for only student^ with incpnplete schedules. The text of both/ fields is 
supplied by the user. • ^ • 

5.5 REGISTRATION STATUS FLAG , Wheij the student course requests are loaded 
by the TALLY program, a status flag is inserted into the recSrd, TALLY 
^initializes thi^ flag to zero. The SECTION program considers only those 
-records with a zero static flag and in turn converts the flag tp minus one. 
The SCHEDULE program prints scjiedules for only those students with a status 
flag equal to minus one or zero and in turn, converts the status flag to plus- 
one, ' • . ' / 

Th6-;registrar, in general, has two options in the registration process, 
' Firsf,.the registrar can choose to honor all requests from a certain groiq) of 
^students by by-passing^ the sectioning program (i,e,, by running cfhly TALLY and 
SECTIdM). tn this way, the status flag which was initializefd to zero by 
TALLY is converted to one ty the SECTION program and th^* resultant schedules ^ . 
will not be arffected by subsequent operations. The s.econd procedure includes 
the SECTION program ^s' discussed above. Once a batch ef requests has been 
processed, the results will not be affected by the processing of subsequent 
batches,' . • . ^ - • * , ^ 

5.6 GROUP SECTION DESIGNATION , ' In most courses, all sections are equivalent. 
However, this need not always be .the case. As an example, a certain section 
of introductory English composition may be set aside for nursing students so 
as to be compatible with the remainder of their schedule. In such cases, the 
sy^X^ must not shift other stucient^ into this restricted enrollment system, 

" ^ This grouping is- allowed for by the grovp designation optibn on the LAB;LIM 
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card. If the group field is blank, the system assigns group designators, 
■ (e.g. Dl for 4ay lecture, LI for day laboratory. El for evening lecture, . 
EL for evening laboratory, etc.). If a group designator is supplied, it 
overrides .the system designation'. Ifi the secti6ning process, fetudent^ will 
only be shifted, to an alternative section if it is the same course and has 
the same gxoxxp designation. 
H 5.7 STU DE NT AND COURSE PRIORITIES . The tegistrar establishes student pri- 
^ ority^'by the processing sequence and the ordering of requests. As discussed 
above, the registrar may choose to honor all requests by sin5)ly skipping the 
SECTION program. In the sectioning process, the "requests at the beginning 
of the queue are most likely to be cfianged ot refused. Therefore, the ^ 
request should be^ubfflitted in increasing priority order (i.e., highest 
priority last per run). ' 

The student may rank his/her requests. The system treats the course 
requests' from a given student in decreasing priority order (i.e., the first 
request has the highest priority). 

S.8 RESULTS OF THE FALL 1974 SSC REGISTRATION > Four separate registration 

batches were run for the fall 1974 registration at Salisbury State College. 

Tne 'results were as follows: 

BATCH 1 ' 'Run Sequence - TaLly, SECTION, SCHEDULE 

Number bf Students 2,605 
Courses Requested approx. 11,500 . , 

Con5)lete Schedules . 1,735 (86.5%) 

Incon^Dlete Schedules 270 
" Miscellaneous* V * 243 

Program 'Failures \ 27 (1.35%) 

CPU Time / ^ 2.5 mint^s 

Co^^)uter Time * / • 4.0 minute^\ ' ' , 



* Oversubscription, nonexistent courses, or a conflict in the requested^^ 
^ courses which could not be resolved. 
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^BATCtf^^^S 3 ; Run Sequence - , SECTION, SCHEDULE ^ 

'^^ Number of Students ^ " ^ \ \ 

Course Requests approx, '1,500 ^ , • , ^ 

Coii?)lete Schedules 270 (90%) ^ 

^ , Incon5)lete Schedules 30 

Miscellaneous 30 ^ . ^ 

- - - - ^ : Program Failures _ . . 0 \. 

^ BATCH 4 Run Sequence - TALLY,. SCHEDULE 

Number of Students approx. 710 ' 

Conplete 'Schedules ^ , 710 

Coiq)osite Run Sequence - tALLY, SECTION, -SCHEDyLE - * ' 

. Number of Students " 2,305 " 

. ' Con?)lete Schedules 2,005 (87%) 

Program Failure 27 (1.2%) * ^ . 
ft 

Overall - " : ' ^ ' ^ 

Number of Students 3,015 

^'^ Con5)lete Schedules ' 2,715 (90%) 

5.9 IMPROVEMENT TO SECTIONING PROGRAM. It was noted that the number of 
incomplete schedules in the miscellaneous category was^ higher than expected. 
A separated run was made with approximately 1,400 requests, primarily from 
freshmen and sophomores, in which the initial requests were analyzed. To 

our great surprise, approximately 18% of th€ J.nitial requests contained course 
conflicts. The program, in such ^ case, woiild accept the first conflicting ^^ 
course and search for an alternative to the second. This process r.ectified ^ 
most conflicts. However, better results could be expected if both courses 
were considered .for alternate sectioning^ The. program has now been expanded 
to reschedule all cases'where ian incomplete schedule results. In the second 
pass, the courses are considered in reverse order. The best result is ^ 
accepted. ' ' ■ ' ^ 

5.10 THE LIST-STUDENT PROGRAM.' The LIST-STUDENT program prepares a list oi 



all registered students^. This' list can be ift either alphabetic or student 
. ' ntnnbex ^rder (APPENDIX III, Saii?)le Listing 9). 

5. 11 THE ROSTER PROGRAM . The ROSTER will prepare four different rosters. 
They -are: • . ^ 

!• Class xoster on. stock paper r^r^- 

Q 2. Grade roster 'on stock paper- 2o3 

ERXC ^* Class roster on printed form 

* 4. Grade roster on printed form . ' ^ 
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Whenever a change in forms or spacing is required, the program goes into a 

\ ' ' ' * ' 

countdown to enable the operator time, to set the printer (APPENDIX III, Sample 

Listing 10). XRis listing ♦shows the echo input specification ducq?. A dunp 

of this type. is prepared Vy all programs which have options. A sample class 

^ roster ap^ars in APPENDIX III, San5)le Listing 11. * - 

i.l2 THE LIST-ROSTER PROGRAM . There are numerous occasions when it Would be 

convenient ta have a^ list of all sections being offered during a giyen semes- 

. ter. This listing is prepared by the LIST-ROSTER program (APPENDIX HI, 

^ Sample Listing 12). ' . ' . 

- 5.13 THE DROP -ADD PROGRAM. The DROP-ADD program for student schedule modi- 

A ' ... 

. fication is noyt being written. A sample listing is not available at this time. 

REGISTRATIOI^ ANALYSIS AND DATA MAINTENANCE . 

'At this time, there are only three prog3:ams in this section of the system. 

They are HUKff, COPY, AND PURGE. '.The DUMP program prepares a listing of any or 

all of the physical record (APPENDIX IV) . The COPY program copies the , 

schedule file onto^a secondary unit. This is normally done at the end of each 

semester, so that a permanent record can be saved. The PURGE program replaces 

,any specified pnysicai record with a dummy record. 

Plans call for a number of analyses programs plus programs to handle grade 

information. * . - ^ 

7. DATA PREPARATION . 

A listing of the data cards used for this sanple listings appears in 
APPENDIX V. While the system writeup is not yet conplete, it is available on 
* request. . • , 

8. CONCLUSION ' ^ ' ' 

It is ray sincere hope that this paper has presented info'rmation which you 
will find useful. We do not have all the answers, but we are continuously 
^ striving to improve the registration process. The REGGIE systep illustrates 
ERIC integrated ^system approach using a single data file. Among the ;5ys*tem,*s 
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stren^hs is hopefully a very teadable printout 'amd a very siwple 
operati3:ig procedure. The major strength is* the sectioning algorithm, 
which JC. feel is superior both in run-time and accur acy to any other 
in existence. 



EDITOR NOTE ; A few output sair5>les of the REGGIE System follows. 

A full set of appendices is available from the 
author on request. ^ 
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, THE COHMIJTEE APPROACH TO USER INVOLVEMENT IN THE ESTABLISHMENT OF A COLLEGE 

liJFORMATlON SYSTEM 

Barb^ara F» Medina, Director of Data Process I ncj,^ Herbert H. Lehman Col leqe,^ Bronx, N, 
Anthony H. PIcciano, Proqram Manaqer, Mefbert H. Lehman Colleqe, Bronx, M,Y. 



1. INTRODUCTION 



In attemptln^q to develoD and implement a Student Information System for 
Lehman Colleqe, we had to face several major problems/ The system was to use an 
Intfsqrated data base approach that would record and report 9n a student's records 
from application until a termination of active interface with the cplleqe. There 
fore, it was fjecessary that several offices reportinq alonq separate organization 

4 

lines maintain and share the same files. Decisions relating to college policy 
on registration, grade report distribution, financial aid information, accessi- 
bility and security of data had to be made by. several apper administrator^ of 
the college. The limitations and advantages of computerized records had to be 
explained to all potential administrative u^^r^s of the system so that the system 
could be desianed as a useful manaaement tool for both* upper manaaement and the 
operational management* Since most of the users were unfamiliar with both uslnq 
computerized flies and with the functions of other offices in the college, which 
would depend on the files for information, it.was necessary to institute some 
*type of educational olanl 

Inl t iai 1y,^ the approach v/e used to try and solve -these problems was: the » 

t * 

. Data^Process 1 nq Department would wri te oronosals and request comments and suq- 

gestions from users. These proposals jncluded the use of softv/are developed at 

other collpqes. This proved to be a slow-^nd .often unfruitful approach because 

the users frequently did not understand the implication's of the proposals. , The 

solution that provided the .proper I nteract ion^ between users and the' data pro- 

» ^ 

cessing project manaqer^Tas the formation of a workinq committee. The committee 
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members now Include a representative of all potential 'user offices and Is chaired 
Uy the data processing project manager. It has connltted Itself to meeting 
once a week for at least two-hours each week until all problems are Ironed out 
and the system«ls fully operable.' Minutes are recorded at each meeting by the' 
project -manager and distributed prior tb the next meeting. Representatives of 

' * . * ' 

the'foltowlng offices attend the meetings^:' ^ v 

Dean of Administration 
Registrar \ ' * 

Admissions ' 
- •' Bursar ' 

\» Dean of Aca^mic Standards ' • . ' 

} Oe^n of School of General Studies 
Dean of Students * » . 
:A smaller group started meeting in Apri 1 ofJ973. This pa>er will cover 
the orogress'of the users^group and^ i Illustrate, from the minutes of the meetings; 
how probtetns are resolved. ^ ^ ; ' 

2. -THE USERS GRnup • • 

1 ' ^ r 

. ■ When meetings were first started in April of 1973, representatives from 
the Registrar's affic'e, the Dean of Students' office and the Bursar met with 
"^theA^r I cation^ Systems Manage.r, the Dir-ector, tlie^roject Manager and the 
Operations Manaqff-r from fh« Data" Processing Department. The user offices repre-' 
,..^ented at these meetings are the offices \hat maintain most of 'the data on the 
course' and student files for the system. 

It was the hope of the Data Processing "Department that It could reduce 

• Its perrrtanent representation on the committee to the pVoject manager and 

, ^ # ' J- ' ' . ^ 

encourage the other offices In the college,' that would receive reports from the 
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file, to send representatives. To attain this goal the minutes of the meeting 
were distributed, to all ootentlal user offices and telephone calls oolntinq out 
particular items of importance, to an office were used as a follow-uo to the 
written communication. . , 

Little activity occurred over the summer, but by September, two new offices, 
the Dean of Administration and the Dean of Academic Standards, were sending re- 
presentat I ves to the meeting on a regular -basi s. Data Processing had reduced 

.Its perjnanent representation to the project manager who chaired the meeting. 
A broad based representation of users is desirable because the reporting 
and evaluation needs of all offices using student^and course data ^e not ne- 
cessart^.Yjj, known to the offices who are responsible for maintainlna the data. 
This laifgk'of knowl^dge)of the functions of other offices l*« not a phenomenon 
unlgue to colleges, h\it Is 'equally true In industry and government agencies. 

% 6y October, 1973, the Dean of the School of General Studies Office was re- 
presented at. the meetings. ^ By ^^^^^ October, tbe Admissions Officer of the 
college, who reports tQ the Registrar, was also attendino the meetings.* 

The. Admissions dff^Icer's attendance of the meetings was triggered by the , 
minutes of a previous meetlno.' The next section of the paper wih 1 use the mln-^ ' 



utes of severdl meetings *tp Illustrate how they have worked to br^incj a potentKa) 
_problem area to the attention of an office and how this problem 



was resolved." 



2.1 Sharing a File . * Th§ ap'proach^we have used to the Student Information System 

is iDodular in nature. The student, f I les are divided Into three Independent sub- 

i.files that are mterralatable by the system. The ffrst of these files Is the 

Admissions File, and the two offices that are the heaviest users of thjs. file, 

' ' " ' ' ' ^ * 

are the Admissions Office and the Dean' of Students Office, The Admissions /office 

uses the f ijes- forcontrol and repbrti^a on admissions and aopjlcaljons data for 
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the college, and the Dean of Students yses the fnfdrmatlon "for placement of" 

students.* There is sbme overlaoplng of reportlnq^^n\«^ds. ' ' ; 
The section of the memorandum reviewing ^the October t7, 1975 meeting of 

the-User Committee dated October 19, 1^73 follows next. Of part I cular Importance 
-^to the Admissions File were items 5 and 6," and dlstrl butlon of this jnemorandum 

resulted In the Admissions Offfeer of the college attj^endlng the next committee ^ 

^meeting to discuss the problem of multiple ^applications to the college (se^ Item 6) 

Item S - Cyc.^ leal 'HodI f Icatlons - Tv«y aspects of the student Inform- 
mat I on system are In ooeratlon. ^ As a rftiultof using the system^, there 
haye been requests to make modifications to some of the prog/ams. 
Data Processing has made some modifications In cases where the, modi- 
fications were needed to jirovide capabilities which v/ere originally^ 
part of the system -design. On th<5se modifications whi.ch would provide 
• added xapabi 1 i ties, however, It wpu-ld be., more desirable, if these 
modifications could be made onr a cycl leaf basis. On large computer 
"systems, It is not uncommon to restrict modj f Icatlons to a once a 
year or once every. six months basis. This is a much more efficient 
use of programmers* time' than, regular modifications.. It^lso allows 
the programming staff to concentrate in estat?l i shing new systems. 
Thl*s item Is still open -for discussion at future meeting. 

Item ^ 6 - Students Admitted to Two Divisions of the College - A ^ , 
potential probleri^ area regarding multiple admissions was discussed 
at thismeetlng. The problem specifically aoplies to students who take \ 
the undergraduate degree and graduate degree at Lehman^ Col lege or v/ho 
take an undergraduate degree. £ind return to take other undergraduate 
courses in SGS. The admissions' procedure requires them to file a 
second application and a hew admissions record must be.es tab Ujshe'd. 
The student historical file must have' the ablll.?y to maintain the 
data on one record but be able t6 print separate, transcripts. Tf\ls 
item will be delayed for a> future meetlri'g i&nd in the meantime, users 
will djscuss the problem In more deptth with Data Processing. [2] 

At the next meeting, on OctoBer 2h, 1973, the ^missions' Officer had 

jotne'd the meetings for the first time. Almost the enti re meet tnq was devoted 

to the Admissions File.- Items 1, 2, and 3 are .of particular Importance. '"The 

memorandum follows. * ' ^ . ' \ ^ 

t * ' 

ItemJl I - SoclaV Security Number VerlfTcaUon fbr the Admissions File - 
The problem^f verifying soct*al security numbers for admissions 
file recordfs ,was; di scussed at some lengtK-'et *thi-s meeting.^ It was 
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Stated that It Is possible that the amount of error qenerated might' 
,not warrant any verification. It has always been the Intention of the 
' ■1(egtstrar to verjfy this Information after the student has registered 
*and not-'^s part of the admissions processing function. It was de- 
elded that members of the Registrar's Office, the Dean of Students 
Office an,d the Data Processing Office will look Into this problem In 
greater detail |ind establish a procedure for verlfylnq.thls Infor- 
mation If the fteed for verification Is warr^anted, 

Item^ 2 - Students Admitted to Two, Divisions of the College - The 
problem of multiple admissions (see item # 6 of the minutes of the 
meeting of October 1<^, 1973)' was discussed ^t this meeting. It 
appears that this procedure Is rather complex and a general rule 
does not apply to all students applying to one division and coming . , 
^from another division of the college, A more In depth analysis of 
tHls problem will have to be undertaken by the Registrar's Office 
^ and the Data Processing Office^ At this, time, no solutlorr has been 
achieved and this topic will be further discussed at future meetings. 

Item #^3^- Tra'fiilng Session for> the Admissions System - There will 
b6 a training sfesslon on Wednesday afternoon at the Focdham^ Center 
on the .methods of utilizing the admissions file. • It will be dlrec- 
,ted mainly to the admissions office personnel, but any admln-lstrator ^ 
Interested In using. this module of the student system.can.benef.lt 
from this session. Please contact Charles' Schreiber as to the exact • 
time and meeting place. ^ ' ' ^ 

Jtem # h - On-Llne Priorities - It was mentioned that the Data Pro- 
cessfng Office hope6 to beg If the design of on-line capabilities 
^fofr student data wltfciJn the next fewx>months_ The users should start 
thinking In terms of establishing which functions (registration, fee 
• collection, grade reporting, general* access, etc.) would' takeprl- 
orlty In, the development of the on-line systems. Related to these 
/unctions is the question- of which data elements should also be made 
available on an on-line basis • Tills toolc vyill further, dis.cussfid ; - 
at future meetings. [3] ' ^ , • 

An acceptable solution to the multlole application problem was reported on 
\ 

the meeting held on December 12, 1973. All. of flees that would-be affected by the 
inethod of handling the problem had been, consulted. Data Processing had proposed 
four alternatives. The original proposals were quite lengthy and a one line 
synopsis oV each proposal appears below. 

Proposal l Adding a new data element, to the file as a flag to control 
admissions d^ta transference. • ' 
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Proposal 2 - Manual delaying of.second application processing. 
Propose! 3 - Adding the necessary duplicate Information to maintain the In-' 
dlvlduaPs record.- • • 
* Proposal k - Adding a duplicate record to the admissions fVIe for all dup- 

Mcate applications. / . ' ' ' 

The discussions at the Ijitervenlng mect'lngs had demonstrated' that the users under- 

stood the Implications of the alternatives proposed .and were capable of evaluating 

* , ^ »' ' . • < 

" •*» • 

.the problems Inherent in each. Two major ' factors were taken into account: ' 

1 . Ease of maintaining the data.. " : ' 

2. Cyc^e of reporting needs of sjeveral user's offices^ ^ 

The minutes of December 13, J97?,, Item # T shown. below, reported on the 

resolution of* the prbblem. 

Item ^ r - Multiple Applications r The pro'^blem of muUlple appllca-^ 
tlons has 4>een the topic of discussion at several meetings. A sum- - 
mary of past discussions held, on this toplc^ (se,e Item ^ 2^ of the 
minute^ of the meeting held Decemb.er 7> 1973) accompanied .last week's 
-minutes. Several proposals or solutions were rendered and the 
- general consensus is, that proposal l^cl seems to be the tnost adequate 
solution to the problem at thts^ time. -Data Processl ng will proceed 
with th4s approach unless a betfer solution is rendered. All declsions\ 
on this matter rest with the Registrar vAo is ultimately resoonstble . 
for the data. \k\ 

The sequence of events reported above demonstVate$^several .things, about the 
approach of design and Implementation by committee. Tfiey are reviewed . In* the 

next section .of the paper. 

/ . ' > 

3. DESIGN ANtX IMPLEMENTATION OF A SYSTEM USING A COM>ilTTEE APPROACH 

~ . . ' ^" 

It Is clearly demonstrated from- the above sequence of events that It Is 
feasH?le to get a solution to a problem through the use of a users committee 
approach, hut It Is equally clfear that a participatory democracy Is a slow 
mechanism for. decision making. The question then arises why should one consider 
this approach. This section of the paper tries to-.give the advantages and dis- 



advantages and the overall commitment needed so that the reacjer can judge for 

himself the. appropriateness of this approacK for designing and Imolementing a 

^ - ; . r % . * ... 

System in his - enytronment. >y " ^ ' . 

3/1 Advantages and Disadvantages , The approach of a User Committee has the 

following ''advantages: ' 

^ ^ K tt offers a mechanism for reporting problems without pointing fingers 
at a particular office, * ' 

, 2. It is a fairly pai^nless method of presenting new ideas and concepts in 
a workshop envi ronrr>ent . "^-i^^ , 

'.. - ■ I 

3. Participants feel they have helped design and Implement the system and 

thus have a greater commitment to matntainin.q the system, 
A. The' Comlkiter Center stops being 3a mysterious place that is changing the 
' world and a tlareat to jobs and security. - 
*.jThe approach of a Usjef Corrmf ttee^has the following disadvantages: 

J. The 'decision process js slow. . ^ 

2.^ Some solutions are compromises and not necessarily the best solution 

'to the 'problem. 

• *^ 

3r Implementation tjme is prolonged and some frustraticfn develops* from having 
discussed' the capabilities a long time before they are actual ly Jmplemented 
^ It rs^equalt)^ Important to poCnt.out that the entire approach is only feas- 
ibie if the representatives sent to^the meeting from the users offices have a 
copmltment to computerize their records and are familiar with the operational 
procedures In tfieir own offices. Experience ha^ shown us that If the mana<jer of 
a department Is not committed to the exteat that he will free operational staff 
to become <»'act I've participants In thefpro'ject , the committee, approach is a^fall-. - , 
ure. This aspect of.aslng this ^proach Is expanded upon below. 



3>2 Cof!*n!tttfent and Approach Needed^ Experience has shown us that there are 
certain approaches to take If success In establishing the system Is to be 
achieved through a user group. The user group should be comM^sed of operational 
or "middle" managers, "Department heads do not necessarily have the grasp of op* 
•eratlonal problems to mhke wise decisions concerning, the! r computeYlzatlon. This 
however, depends upon the size of the department. The representatives of the de* 
partment must be able to make operational decisions and must be committed to the 
establishment of the nev/,system. The latter condition U most Important and must 
be shared by department heads and top administrators as wefll. Top management must 

<• . • • « - - • 

also license and sanction the users group to make.declslons» They can and should 
express approval or disapproval with the decllslons of the users group. All 
pel Icy^decls Ions which mfg))t arise at user's group meetlrrgs should also be re- 

i 

' ferred to top management^. A failure on the part' of top management to respond to 

* • - f 

^r/»ferrals or Inquiries made by the grouo can be interpreted as a sign of disin- 
terest In ,the,work of the user's group. This disinterest can spread to the mem- 
bers of the grbgp, and if it does/ the effectiveness of tne group can be severely* 
Jeopardized. Although, top management shouW express Interest In the groups they 
should not be regular attendaAts at group meetings. A:n admlnlstra'tor or manager 
who Is'in a, very Influential^ position, carv eas I ly .dominate a meeting and hinder 
an open atmosphere for discussion. A free and open atmosphere Is most Important 
in solving administrative orobleme and In establishing a new system. The chair- 
man of the,qfoup shouH be awai'e of t4vf-& aii^-shouW try ttr^uafantee"^hat e f?*€e 
atmosphere does exlst.^ This can be accompl Ished by using such techniques as 
assuring, anonymity In all mT^utes of the meeting so that members feel that their 
Ideas and not necessarily themselves are being recorded, Correspondence to and 
from 'the gra^Jp should be addressed to the group or to the chairman, and not to * 
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I nd'lv I dual members of the q'^oup. - 

^ The paper reviews an •approach to solving the problems of user interface 
inherent In uslnq Integrated data base management techniques. The approach of a 
user cofnmlttee for design and Implementation of a major system has been used 
successful ly 3t the authors L col lege, but there are real limitations to the 

, approach. The crucial factors to evaluate In deciding whetlier or not to try 

this approach Is the length of time that is acceotable for full Implementation 

r ' 

of the system and the commitment on the part of managemer^t to computerization of 
> 

their records. If it is Important to have' immediate implementation of a system, 
the committee approach is probably not a satisfactory approach to producing the 
interactions needed for integrated data base systems.. In addition, if the 
•managers of- trte groups that must Interact are unwilling or unable to commit 
their operational Deop-le to real participation In the decisions of the conmlttee 
^Ke approach Is doomed to failure. • 
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FACE TO FACE WITH DATA BASE 
(ON-LINE, REAL-TIftE) 



-Glenn B.' Harvey 
Director of Computer Services 
DePaul University 

This paper logically follows two earlier tre2itmeais_pf^this subject 
entitled GETIIHG TO FIRST BASE WITH DATA BASE and ROUNDING SEC9HD BASE 
tfl TH DATA~BASE . While the over-all system in these papers is the same, 
the first placed emphasis on the^at-ch maintenance aspects, the second 
•targeted on the methods for retrieval of information, and this one 
describes the terminal interface that permits users to access, and update 
their files. 



INTRODUCTION - DePauTs Early Computer Environment 

DePaul University has always followed a tight budget philosophy / 
toward computers and data processing. This is altogether consistent 
with the University's goal of providing a cost effective prpgram in 
higher education. • \ 

DePaul has approximately 1-0,000 students ;3^ver 525 faculty and 
over' 40,000 graduate alumni. An additional 250\000 people have taken 
educational programs of some duration at the University. • 

The 1974-75 operating budget is approximately $20 million, nearly 
four times the $5.5 million budget of 1963-64. . 

Strict control on the' funding of computers paid financial dividends, 
but left a widening instructional gap for OePai/1 graduates who learned 
little about the electronic marvel . Pressures from both internal 
and external sources became' stronger to expand the computer resources. 
By late 1971, this resulted in the acquisition of new high-level staff 
experienced in the application of computers to both administi;'ative and 
instructional systems and dedicated to the .proposition that computer 
systems should service. users in unique new ways. ■ . 

. DECISION TO GO DATA BASE 

To lend continuity and control to Systems Plahning and Development 
efforts, a Master Plan for University-wide Computer Services was written 
and presented to the Executive Committee for approval. This plan out- 
lined the alternatives for computer services avall^le to DePaul, their 
associated costs and benefits. _ ■ ' 
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included were- recommendations for hardware, software, staff and 
an implementation schedule for application systems.. Obaectives to 
.be achieved bj^new systems required that they be: * 

* Responsive - To changes in user needs regardless 

of timing of source of change. * - 

* Flexible - Able to provide for new files, new data 

in old files, new methods of processing Old data, 
eqtire new systems, or whatever need arises. 

* Simple - Easily understood by users of data, as 

well as the computer technician. / ^ 

* Self-documenting - System should provide relatively 

conplete documentation of itself as a by-product * ' ' 

^ of its own operation. 

* Parameter-driven - Mast functions to be handled by 

entry of control cards or talxles with tailored 
programming held to a bare minimum. 

* User- control led - User should have high degree of 

control over his own data files, their content, 
- maintenance and usage. 

. * Easily-converted - Little difficulty converting 
existing 1401 files from old to new systems* 

* Economical All of the above goals should be * 

possible on relatively low-cost computer equip- 
ment^with small memory and few input/oUtpui units. 
Staff expenditures should likewise be mini.mal 
. ' yet able to accormodate syste'^. demands and changes. 

Hardware selercted was an interim System 360/30, 96K memory, 
4 tape/3. disk, computerate be follov/ed by an. IBM System 370/135, 
with the same memory and input/output units, when available in 
January 1973. The 3 disks were originally 2319. replaced by double- 
density ITEL disks in August, 1972, thus making approximately 175 
million bytes of storage available on-line. The interim hardware 
.was installed Ma^rch, 1972. 

It was recommended and approved that the new machine system 
be constructed using Data Base concepts. That is, files withirj 
.-the "data base" would be logically inter-related in a network 
fashion. This had the obvious advantage of permitting the develop- 
ment of application systems that could easily retrieve new "relation- 
, ships" pf data, i.e.., new infomation for new uses, rather than just * 
the data themselves. Traditional file-oriented machine systems are 
programmed to contain specific data relationships that satisfy needs 
a't a point in'ti^, but are time consuming and costly to reprogram 
when changes occur in the ne§ds for information. * . ^ 

ERiC * •^7-<i 
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SELECTIOH OF DATA BASE 'TOOLS 

Several decisions -were also made in regard to-«sxisting computer 
software that could aid DePaul's development of a 'Data Base System. 
Much time was devoted to seeking out and evaluating "packages tfiat 
purported to cure an organization's problems. ^ 

While inVestiaating one« such product (a data base/ management 
system) called TOTAL, we learned of its use atAmherst College m 
• Amherst, Massachusetts. Amherst had 'developed a generalized maintenance 
' system using TOTAL as the "super-access" method for orsanizing its • , 
disk files. Their approach to data processing prgblems appeared to - 
us more advanced, responsive, and flexible than any other we found. 
The Amhers.t example became the foundation for the DePaul system herein 
described. ' 

For our entry into the world of Teleprocessing^ we selected a 
. package called CRT- Interface, marketed by Westinghouse Tele-Computer 
Systems of Pittsburgh. This package requires minimal memory for 
operation (32K partition), permits COBOL programming of TP jobs and 
,cost DePaul $900. 



DATA BASE SYSTEM STANDARDS 

•The DePaul System is really a Data Management System . It is 
composed of four basic parts: 

♦Generalized Maintenance System (6MS) , . ^ 

♦Generalized Retrieval (and Reporting) System (GRS) 

♦Generalized Utility System (GUTS) 

The fourth part permits TP in^quiry. update into tha Data Base and 
is called Generalized Terminal System (GTS). This paper principally 
treats only the, last system, our terminal interface to the -user. y 0 



GMS Job Stream 

A single batch job. stream GMJOOl exists for the maintenance of 
any and all files in the Data Base. All files can be active in the 
same run, that ir, incoming transactions can be targeted for any 
Data Base file. It is expected that only one GMS run will be 
reguired each day to maintain aTl such files. The Syston Flow in 
figure 1 shows input transactions being converted to disk via the IBM 
card-to-disk utility. Program Gf-lOOZO edits each transaction thoroughly, 
flags those vflth errors and .releases them all to the update program' 
GfiOOSO. Gf40O30 is a calling program that calls the generalized module 
XX0900 to process all direct changes to thr appropriate Data Base files; 
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'A direct chanae transaction uses one of the transaction codes. showfi 
in Figure 2. - In effect, such transactions affect no file or item of data 
except that which is specified in the transaction itself. An example 
wouid^be the recording of a student being registered in a specific course. 

Gf-10030 can also call numerous other update modules for the purpose 
of making indirect changes. Tailored programs, such modules are triggered 
by the type of ♦transaction entered into the job stream. Thus, in any 
given run, many different types of files, activity, and indirect changes 
can be involved. An example. of an indirect change could be the setting 
of an Enrollment Status Vhwlicator, in a different filev when a student 
enrolls for arr^ course. ^ . ' 

GH0040 prints all error,, unposted transactions that entered a given 
run, while GM0050 -prints the posted conditions. In addition^ GM0050 
analyzes the users of data posted and generates, to multiple users if 
necessary, monitor reports of records that have changed; 



Parameter-driven GRS 

At any time*, and at regularly scheduled reports, the GRS capability 
permits extraction of records from one or more Data Base files with or 
without sorting, for the ^Jrinting of reports (lists, labels,. accounting 
reports, -statistics, etc.) all by parameter entry. At least 80%^of^the 
computer center's output is handled by the generalized Retrieval v« reporting 
System. 



Data Base Standards of Construction 

Constraints on construction of the DePaul Data Base were established 
in order to use the GfIS to maintain all files with but one update module. 
First, some definitions are in order- ^' . 

♦ Physical File = Grouping of similar records within the Data Ba^. 
TOTAL permits two types, master or single-entry and variable 
or variable-entry. Each .is identified to TOTAL by a fctur-letter . 
name-, such as PEOP (for a PEOPLE file of names, etc.) 

*File Record- = Logically unique data grouping for a given primary 
control. 0 ike Soc. Sec. #) in the^ase of a- master file. A . 
variable file record needs both-<-^ijnary control segment and 
' • * secondary control (part of SEGl) ro establish its uniqueness— 
and "thus GHS can find the record when trying to -update ith 

♦Segment = Grouping of data elements v5ithin a file record. CTRL - . 
segment contains only the primary 'contra! eledient. 
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A data segment, i,e, SEGl, can contain any'number of "data 
elements. ^ * • ' i 

*Data Elements = Usually the smallest data component ofm segment. 
System permits multiple definition of elements - ^ ^ 

While the QMS programs could be modified to accommodite almost any 
type of Data Base system, the setting of standards within bur own ^has 
greatly facil i tated the development of new methods .and teqihniq^es for 
dealing with the data contained therein.. 



Data Base Dictionary of Elements ^ o 

♦ ^ 

Several files in the Data Base arefused solely fcTr, control of the 
system. A schematic of them is shown in Figure 2A. . Pernaps the most 
important is the OICT or Dictionary of Data Element File, Every el^ent 
IS described in DICT, its associated file, segment, beginning posi'fion, 
sire-^ class, i2tc. Each element has a unique number and is structured in 
'a special v/ay as seen in Figure 2. An element in the DePaul system is 
related 'to physical file by its prefix, 

^ In the final analysis, the DICT even describes ttself,'as seen in 
-Figure 4.. Here, it can be seen that 22 elements compriseone DICT record, 
21 of which are in SEGl and 1 in CTRL segment. A 23rd' element really ^ . 
exists in DICTSEGl positions 1 - 6 known as "last transactiori. date'* 
which is automdtically supplied and maintained by the GHS. because the' 
Diet can describe itself, the GMS can be used to uf3date,the DICT records 
of any element. *In oth^r words, changes to the structure of the system 
are as simple as* changes to the data. / 



Data Base File Relationships 

Another system coiitrol file/FILS describes the characteristics 
of each physical file hnd.its relationship) to others, in the -Data Base; 
see Figure 3 for a sample Data^^ase Schematic and Figure' 4 for the • ^ 
associated content of the FILS file. Ah interesting fact is that FILS 
can^fexist under any data base^ access method (not necessarily TOTAL). 
File relatJonships are also /carried in the TXITAL, core-resident descriptor 
nodule, but that is frequen/ly proprietary; changeable, or the vendor may 
even be changed. Like oth^r data-base files, FiLS can be modified 
through GMS. FILS and DIQl" along with the. attendant standards of data 
base construcjt,' terminology and fije relationships, fom the heart of 
th^ DePaul system. ' / v"- 
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Data Base Input Processjqg 



• Perhaps one. of the mqsi interesting par.ts, and certainly the 
^/atch-dog^bf this sjrstem. is 'Input Editing/ This j*s also generalised 
arid is a separate front-end sub-syste?i/ Its purpose is .to provide 
broad 'capabilities .for, entering either single-element or 'multiple- 
element transactions in a relatively free-form, highly fle^ib^e 
' manner that insures that transaction values are t:Drrect, . ' > 

'System Control Files involved include*the/FORH njaster 'file arid 
FUSE {Form USagE) variable file that together/def ine the detail lay^ 
/put of muTtiple^element transactions. For e)iample, 'in Figure 4/\,^ 
assume a certain input form j?F35 requires that two cards be punched ^ ' 
with data comprtsing three elements on the first card and ten elements 
X)n the second. These filesWould show the following: , ^ ^ « 

' \*FORH - xlesignates the Form #F35, max. no. of cards = two; 

fnmary Control # (Soc.' Sec. #) starts in^cc 1 and , 
ends 'in cc 9'vteTement data thus starts in cc >D-)' 

•> and a pointer .to a FUSE file chain of records where: 

*FUSE - For card Form F35,> first element value in cc 10-40, 
second element value in cc 41-50 and third ejement 
in cc 51-68. The appropriate element no. for each is 
also given. . • 

For card #2, ditto for 10 elements. 

th-this information, the system can "explode" multiple-element trans- 
tions intg, their component single-element versions tihat. are acceptable 
to the GHS update modu-les. >^ • . 

/• . " > ^ . . 
When, a singlerelemenf transaction is identified (or created via 
"explosion"), the DICT record- for that element no. is re^d from the Data 
Base. Armed with its element characterises, validity of .the trans- 
actions data class, length of vaWe bein|^tered, ai^thorization of-.dept. 
no. , validity tf "system" na, etc. can be 'determined. .' :■ 

Then, two new System Control Files TABL and VALU are brought iifta, 
play. Another master and variable file combination, like FORM/FUSE, 
these Ailes- contain the range of expected, or precise-, values for any 
given element. The transaction v^tje is subjected to the proper validrty 
'■checking bV these fi-les before successfully pa^fing into GM0030. 
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Some Han<lware Corrsi derations 



The batch or TP'systenj^ designed to occupy no my;e than 48K of 
memory for any program ra(53ule" For insfaqce, the update phase GM0030 
can tnclude *in merpary ax one..time:^ V-^ 

*Rdpt Module GM0030, MacrpS " ' .V 
' ' *TOTAL Data Base Description Module fSi^e varies)^ ' " 
r *TOTAL Data Base Manager , . 

♦Transient COBOL modules like XX0900" / 

A 96K IBM 370/135 easily accomodates th^is system at a very modest hard- 
ware cost. "PVogramming language for all primary .modules is IBM, COBOL D. 
There are itlsp 3 macwos written i-n Assembler, each ^bout 15 instructions. 
The system i^ thus highly hardware and software-independent. Operatfng 
system is DOS. . ' ^ . ' . 

Three additional 4nstallat>ons of the batch system have b§en made, 
two of which are OS with' programs conv-erted to ANS COBOL. 

^ Our double-density ITEL disk drives are able to provide concurrent 
» operations among. \^) 1401 Emulation, (2) Data Base Batch Processing*. 
(3) Data Base Teleprocessing, and (4), Spoofing of 1/0 .operations . ^ . 
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M BASE FACE TO FACE - GENERALIZED TERMINAL SYSTEM 



System Components . * - ^ 

A rather intricate combination of hardware facilities and special- 
software is needed to build a teleprocessing 'system. The following 
discussions of the subject are purposelyjsimpl ifie'd and, hopefully, 
'clarify DePaul's^ Generalized Terminal System. ^ 

1. Hardware Employed 

* Configuration - ' • - - ' ' 

IBM 370/135 configuration, -Including , the -TP terminal networJk. 

* Terminals - Five CRT terminals of the 'IBM 2260' type ar'e used. 

Screen capacity is 960 characters spread over 12 horizontal 
^lines of_80 characters each. "The" terminal keyboard layout is 
much likB a ?ypewi>titer.wit|^ the. addition of several special- 
function keys. ' ' \ . ^ ; 

Pressing t^e St*rt-of-Message '(SGM) key creates a character 
. symbol t> that is the beginning of the message to be sent -to 
the computer. ' The TRANSMIT* key activates- the computer X6 read 
the screen current message and places an End-of -Message 
, (EOM) Q symbol jrl the cursor position. , * 



Thus, the ch^racWs 
reading only tfie ABCD. 



) 



► A3CDIeJfG{^ .would result in th^ computer 



> * 



Network Operation - One control unit services all 5 terminals 
by creating a. polling sequence, to repeatedly check each 
terminal for activity.. The computer actually communicates , _ 
with the control unit, only, by i^ssuing read-screen or .write- . 
screen coinnands-. , : • 

Such commands state the specif 4c terminal number involved and 
the expected length of t+tf read/write character string, up to 
960 Characters , f ' 

Writing, -.from computer memef^y to terminal screen, .always starts 
at the first character .position on the-^creen, at the upper ^ 
left or 'home' position. -The operatQr's response to the last 
screen written is what is read from '^he screen to computer. 

' ■ . • ' ' y 
The message being read is always defined by the hardware as 
the characters on -the screen that lie between the SOW and EOM 
characters symbols. Only one SOM or EOM can be on the screen 
^t "onF tTme -' thVsTs -general ry -errforced- by-the ^1a^dware•^ — - — 

We have a local terminal network, where in no 'remote' or 

phone transmission is involved. Jermina Is may be placed up 

to about 1000 feet from the control iji^it connected by a cable.. 



local networks are less expensive than remote since no data 
transmission facilities are needed, and havd extremely fast 
screens (read or write time) . . virtually instantaneous.. 

Howfever, the time to read or write a screen is*not a' signi- 
ficant part of total 'response time' as coirenonly defined. 
Response timi' is considered the time it takers for the computer 
to 'answer', that is, to begin writing a screen tn response 
to something the operator entered. Depending on the circumstances.- 
response time varies greatly from onS teleprocessing system to 
another.' The DePaul system is quite good in this , respect, 
averaging about 3 seconds. 
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1. INTRODUCTION 

The University of Texas at Dallas (UTD) is an uppey-level 

university located in Richardson, Texas, » which is a northern suburb 

immediately adjacent to Dallas, It was Originally a private research 

cfenter. In 1969, it became a part of The ^University of Texas System.' 

UTD immediately began offering doctoral J.evel work, and in the fall of 

1972, initiated several master level programs to support the doctoral 

programs. In the fall of 1975, The University of Texas at Dallas will 

be^come an upper-level university by-enrolling its fii!'st undergraduate 

st^idents at the junior and senior levels. - 

UTD is a user of the University of Texas Regional Computer Center 

in Dallas, Texas;, which al^o supports The University" of Texas Health 

Sciences Center, in Dtallas, The Ur\iversity of Texafe ^ Arlington, and' 

other smigiller users. The present hardware is an IBM 370/155, five 

*tape drives, four 3330 disk drives, and other periferal ,equipment. 

The present software is OS/MVT, TOTAL Data Base Management System; an'd 

no TP J-tonitor or Query Language, 

A ^tan^ing genferlb. requirement of the administration of The University 

of "Texas at Dallas is to receive high quality information with a maximun\ 

turn-around time of one day. TKis implies some kind of on-line inquiry^ * 

and updating capabilitieSj It implies *file structuring fot ^eff icieYft • 

accessing of data elements. It implies a ^query langufi^^* with supporting: ^ 

to 

software to be able to quickly describe inputs, outputs, and pronensinF. 
to be done. With this in mind our approach was to. make any provij^ions we 
could anticipating a ^TP Monitor and query language at a -later .date to 
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develop batch systems whicft access records in direct or sequential 'mode 
using the TOTAL Data Ba'se Management System, and design- all data collection 
forms and reports which will bfe replaced with on-line" inquiries ta fit 
Vithin the physical limitations of a CRT screen, • ^ , - 

With a very small research-oriented facviity and student body, the ' 
University needed to begin a program to create, interest in UTD among 
prospe"ctive enrollees for the fall of 19T5. The program chosen is called 
Concurrent Admissions. It is designed much like a regular admission's 
system, but is flavored heavily with counseling services and does not 
require the prospective student to supply more than what is asked on the 
application. The- program provides advanced counpling to prospective 
students 'Of the University while they are completing their fiVst two years. 
The bulk of the students -participating are; enrolled in area community , 
colleges, Jid are In' a position to visit the UTD campus for couliseling 
as often as they feel riecessary. However, UTD counselors also travel 
extensively to -community college and high /school campuses to reach as 
many prospective students as possible. /To support the effort, a computer' 
system was designed and is, at this time, approximately ninety-five percent 
•implemented. * ' , * 

The Concurrent Admissions System^is situated logically, aS" in Figure 1 
between a variety of documents from and to- prospective students, ajid the 
regular undergraduate admissions system. . It provides advanced counselfng 
,to prospective students of UTD, while they are completing their first tVo 
.years at a community college or 'some other- four-year college. The system 
is promotional, in natip-e and is where the' student 's record pay be created 
...... W . o.. V... ..U ...... ■ .. 

.graduates- or leaves UTD. 



Ap^ucAricju 




— ' ^/ 





































FIGURE 1. Concurrent Admission System Environment , ^ 

The Conc\irrBnt Admission System itself can be thoiigh of as five 

general 'areas. They are: "(l) prompting inquiries; (2) prom^tlnfe^ 

* * * * ^ ^ 

Concurrent Admissions applications;' (-3) creating emd maintaining a 

Concurrent Admissions data hase; (It) uSing. the data base; and, 

(5) prompting regular undergraduate application^ fpr admission. 
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i.l Prompting Inquiries . Inquiries- . about undergraduate 

degree programs ai:e prompted as^hown in Figvire 2 by ^I^cing newspaper ads, * 
radio and TV spots, haying booths in Ipcal ^shopping centers,, displaying 
' posters at advantageous locations, and by sending letters to all people 
on'such lists as: (D^National fterit Scholars;^' (2) Dallas/Fort Woth High 
School Graduates; and, (3) Educational Testing Service's Minority Search, 
' Valedictorians, and Salutatorians . Additional inquiries result from , 
(l) personal letters,. (2) walk-:^ns, and (3) phone calls. A stand^J-d 
Inquiry card is filled out in' the office as each inquiry occurs. Another 
soitrce of "inquiry" is from ACT and SAT Test Score Tapes. Eaph entry on 
' ■[ these tapes is treated as an inquiry and* entered in the data bkse, 
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^FIGURE 2. Prompting Inquiries 
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1.2 Prompting Applications' Applications (Appendix l) for Concurrent 
Admissions are prompted, as shown in Figure 3, by (l) coxmselors traveling 
to ar^a campuses and talking to prospective UJD students, and, *(2) period- 
ically having the comput^er examine the data base and generate a follow-up 
letter to be sent along with a blank application to all Virfquiries' who 
have not yet submitted an application. 

To supplement these direct efforts, pertinent literature is sent to 
selected groups indicating a certain major or attending a certain insti- 
tut ion, etc, * 
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FIGURE 3. I?rompting Applications * * 

1.3 Maintaining The/l)ata Base . The ddta base is hiaintairfed as shown in 

/ ' ' ' 

' Figure h by adding all applications and inquiries to the file on a weekly 

basis. They are, edited. 'The data b^se is updated'.' Mailing labels are 

created for (irst tilme inquir/i6s,^ Back-up and recovery procedures atci 

executed,' 
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FIGURE .U. Create and Maintain Concurrent Admissions Data Base ^ 

Using The Data Base , The data base is then used for a variety of 

purposes as shown in Figi^e 5- .They arei (I) elaluating 'applicants for - 

admission; (2) re-evaluating rejected students fpr admission assuming 
* »k 

* * 

possible submission of. more current data; (3) doing various lists and 
s\aMaries; and, making mailing labels. A use of major interest is 
• 'that of evaltiating students for appectance. They are accepted in one of 
four ways: (l) rank in the top half of .his high school graduating class 
and make at least l8 on the ACT, or 800 the SAT; (2) complete at least 
27. semester credit hours with % grade point average of at least 2.5 on a^ 
U.O system; (3) complete at least 5^ semester credit hour's with a 2.0 
average on a U.O system; or^ be accepted on individual approval. ?'hose 
accepted are sent an acceptance letter and a View Boo"k about UTD. Those _ 
rejected are sent a rejection letter explaining conditions he/s^e must 



/29i 



Vol, II 



meet to "become laccepted. Ajiothfer important use is. providihg lists 
for counseling! purposes. Still another very valuabl-e use is for 



planning faci]|iities an^L Student Services. 



DATA' 



FIGURE 5. 'Use Data Base 



1.5 Pronipt|ing Regular Undergraduate Applications . '.The last general area 
in the system is, as in Figure 6, prompting the student to apply for 
regular admission. The expected date of enrollment is e:?:amined, and for 
all students indicating first enrollment' for the coming semester, a 

computer generated letter is written explaining the ^teps for re^lar 

' 1 • ' \ * 

admission^ There is one letter for thosfe who have been accepted-and 

! ■ \ 

another for ^hose who have not. The letter to the unaccepted ones\ explains 

any deficiencies and reiterates the requirements. ^ \ , 
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FIGUI?E 6/ Prompting Applications for Regular Admission 



2> - T HE DATA BASE 

— : . ' 

2.1* Data Elements . The data elements needed in the system were decided 

upon at meetings of a group of administrators designated by the Academic 

Council. The participants were people such as t^ie Director^of Admissions, 

Registrar, Director ^of Student Services^ tlTe Assistant to the Vice 

President for Academic Affairs, and others. As each- expressed his or 

her information needs about students, schedxiled to begin enrolling in' 

.approximately two years, a* list of data , elements emerged and an ^application 

for Concvirrent Admissions was designed. One document Supplies- all infor- 

mation needs expressed by the aforementioned parties as in (Appendix 1^. 

2.2 Logical Data Groups . The next step was to decide where eac]j^ata 

element should be maintained. ' In TOTAL, there are two kinds of files - 

meaning that for any key there is one and only one record in the master 

file. Masted file records are read directly, and^ point to the first record(s) 

of all chain(s) linked to this master record,. Vai^iable files are multiple 

• entry files meaning that the number of records in a variable file is 
* • 

I r 
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limited only by the physical limits specified in the Data'^BaSe I 
Generation (DBGEN). ^Jariable files must be attached to a;aaste2^< 

' file as the address of the first record, of a. string is maintained- 
only in its master record. Each record in a string is lijiked both 
forward and backward, allowing appl^Lcation^ programs^o 'write "before '* 
or 'write after' a variable which has already been read. ' . 

The decisions made here vill have far-reaching and long-range 
effects on the efficiency, effect ivpieas^ flexibility, and maintaili- * 
ability of the system. The designer must seek answers* to such 
questions- as: (l) Will disk space be a constraint; (2) HowV and 
hQw often, is each data element used? (|3) Does ^ach element exist 
only once for a primary key? (h) Does it alwaiys exist? (5) Can each 
element exist more than once for a primary key? (6) Which set of 
elements are used for each logical system function?^ (?) Should all 
singly occurring elements be in the master record? (S) Should tlieyf 
be in the master if they- don't always eSctist? (9) Should all elements 
be in variable records? (lO) Should they all be in one variable 
record? (ll) Should they be grouped in variable records according 
to logical system functions? (12) Should they be grouped in variable 
records, according to frequency of usage? (13) Which arrangement of 
elements allows the simplest application program , logic? (ih) ^ Which i 
arrangement of elements "allows the most efficient execution by 
application jprograms? (15) Which arrangement most easily allows 
expansion of the data base? (16) etc. The answers to these questions 

must be determined within the framework of the functions the system , 
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mist perfonn, and the resotirces available to develop and support the 



/ 



(- 



system. Our decision was to minimize resources^ ThisShen' lead to 

V 

the development of the Data ^^Base File Chart* * 
2.3* Data Base File Relationships . In minimizing resources, we. had to: 
(l) srimplify program writing and maintenance; (2) Use as little 
permanent disk space ap' possible; (3) provide for easy hack-up an<J 
'^recovery; (h) provide for easy exf)ansion of the data hase; (5) 
minimize execution time; and {€) start simply enough as not to reqiiire 
excessive training and planning hefore beginning. 

Since the system is extremely person oriented, we agreed that *the ^ 
only type of on-line inquiry and updating we would have to have later 
would he by person. All other summaries eyid reports could be run on a 
remote batch printer. This then made the File Chart a simple one. The 
master file contains all data elements occurring only once. 



* / 

FIGURE Data Base File Chart ^ ^ 
^ ^ *# 

The' variable file contaiii^' all data elements occurring more than once, 

♦ 
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In complying with ovir criteria for minimizing resources, we now 
* * * • * 

had to determine how each logical system function would be accomplished- 

with this'data base,' The system functii)nfe are: (l) update student 

records; (2) e-^aluate student records forjiaiimission; (3^ write Hatters ' 

to Students; and, {k) inquire into the daiir^base; on-line by student » 

(later), and other summaries euid reports (now, batch). 

Program logic is simplified because updating, evaluation letter 
writing, and on-line inquiries are all done by student ;' etnd aJLl data 
for *a student is in the* master , record except the correspondence log 
which is kept in the' variable file and is a by-prdduct of the evaluation. 
The other summaries and reports are done by extracting the master file ' 
and writing a batch summary and/or report. 

Disk space is minimized because very little extra space is in the . 
master rebords and the number of master recprds provided for in the 
data base above the number of records used is kept to a safe minimum, 
Also^ there is an absolut)p minimum number of linkages in the dkta base. 

Back-up and recovery was made easy by inserting a time-stamp in 
a master record following its update, . This' way if the system goes down^ . 
during §ui update nin, the run need only be' resubmitt^ without regard to, 
the transactions or the data base because the update program always 
checks to see if it has already updated a record by comparing time-stamps 
and will not attempt to update a record it T(\as already updated, Expannion 
of the data base is accomplished -by using the back-up and recovery system* 

Execution time is minimized for all functions except in the case 
of extracting, sorting, ant writinig^ summaries and/or reports, and this 
is not critical because of the frequency of these runs. 
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Ohe can start as simply as we have and gain experieniie because^ 

/ 

. we have avoidfed some -of the problems of a large data base; such as 
back-up recovery efficiency, system complexity, program complexity, 
disk space management, and maintenance gf secondary master files. 

One question which was of great concens was: "Will the secondary 
master files cpntain-'all possible keyfe or only those existing in a 
variable record?" The implications of this area: (l) If secondary 
master files contain all possible keys, then an update program would - 
have to be written for each; , or,, (2) If secondary master fi^es contain 
only those keys existing in^a variable record, th^j^ tfte u^ate program' 

' for the primary master file can automatically updaW the secondary 

master files as a variable record is written with ^^ke^ which does not*' 

yet exist iu the secondary master. 

3. THE SYSTEM ' ^ 

3.1 - Prompting Inquiries . In; this phase, lists of student tiames and 

addresses are keypunched. Each type card is read by a modtde which 

K 

builds a record which is passed to a: general letter writiAg modiile. 
This module i>rints letters 9n continuous form letterhead ^(Appendices 
6 and 7) and they are sent oilt with inqviiry reply cards (Appendix 2) 
which, when returned, get the student on the file as an "inquiry". 
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' FIGURE 8: System Flov - Prompting Inquiries 

• 

3.2 Prompting Concurreflt Acimission Applications . A program examines 
the data base and generates follov-up letters (Appendices 6 and T)".for 
all students vho are inquiries. Along with the letter is an api^lication, 
tor -Concurrent Admission (Appendix l). .aIso, mailing labels are written 
by request to send special literature publications. 
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^ flOTRE 9, System Flow -.Pron5)ting Concurrent 
c AdjjLission Applications * 

3i3 Create tod^ Maintain Concurrent Admission Data Base > This phase is 

where,^ the "data bas6 is built (Figure 10) and all additions, changes, and 

deletes are accomplished, la,bels-.^e created for first inquiries, and 

back-up and recovery procedures are? executed, 

.The^data base was creat'ed initially by writing* a dne~time program 

Sump the old s,equential disk fil6 to a' temporary di^ file in trans- 
on record format (all additions)' which was then, input to the data 
base update job. ^Normally the update job is accomplished by kejrpunching 
•cards for applications, inquires i and internally originated ^file change ^ 
forms; and processing the weekly accumulation. As inquiry transactions 
are encounter.ed, a check is done to see if it is the first one for the. 
person, and if so, a mailing label is written. Each time the update job 
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is run, the back-up and recovery steps pack the transaction records 
and save them until the .next ^ dump of the data base. The data base can 
J)e, recovered at any time by restoring the last copy, unpacking the 
saved transactions ,Vnd running the update job. 

3.U Using the Data Base . Here applicants are evaluated for aglmission 
(Figure ll) by a progr^>rhich accesses all 'records 'in the data base 
and applys the admission" algorithm to alV student records vhich eire 
unevaluated or have been rejected. It uses an \inlinked TOTAL master 

file for obtaining a copy of the acceptance ahd/or rejection letter 

V "k — ^ 

that it writes. It writes mailing labels for 'all students who are 

- . } % • 

accepted, for sending additional pertinent literatvire. It provides a 

log of all action taken, and creates a transaction file for the update 

program which then updates the student's status. ^ 

* 'There is a program which will list or summarize the file^oii^ny 

/- - * 

six, fields in the master record in any order. 

There is a mailing label ^rogra^ vhich will print a set of labels 
for a- specified group of. records. * , 

There' are other uses, ^ but those anentipned above ai^ the primary 
ones. ' - . 0 * 
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FIGURE 10. System Flow - Create and Maintain 
Conciirrent Admission Data Base 
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' "tlGURE^ll. System Flov - Using the Data Basfe ' 
'3.5 ^Prompting Regular -Admission Application^ / PromEtirig of regular 
admission applications by the system is done hy a program which accesses 
all records in the data base and examines the expected date of enrollment J 
to find ^hose scheduled to eifroll ^ the coming .semester. It writes a ^ 



I 



letter, to qJLI these with an application and makes a log of all action tak^# 
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•FIGURE 12. System, Flow - Prompting Regular Admission Applications 
> ^ . . IMPIJ]^IENTATION 

' " The iwfementation plan included maintaining a partially developed 
seiiuential fil'e syst^, while the remaining parts of the system were 
developect^ for a Data,j3ase Management System, Then the original programs 

were* converted to ^ run* from 'the data "base. ' • / 

^^>-v ^ . . . . 

* - TheTinllial system" development using the Data Base Management 
System consisted of programs, to: (i) dump the existing file to trans- 
^ctibn .format which could' be^read by the new' update program to "build 
ttfe data base initially;, updat^^Cbuild) the data base; (3) back-i^ • 
and recover 'the d,^ta base; and, (U) evaluate applicants fpr concurrerjt 
'admission. Then the Detail List /Summary /LaVel Jot^.'was converted to run 
JTiRom Data Base and the conversion was completed. 
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, ' APPIICAHON FOR CONCURBENT ADMISSION ^ 

. . TH'E UNIVERSITY^F TEXAS AT DALLAS 
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e Dai:a Base Design ^n determine the success or failure "of 

ems. Data Base structure's must be reliable and responsive 



On-line sysl 

^during th^ hsat of en masse registration. 

This paper presents a reliable yet relatla^ly- simple Data Base 
structure designed for on-line Admissions and Registration which is 
quite adaptable to other applications* 
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1. IirrRODUCTlON ■ . * " ' ' . 

• "More colleges and universities are usii^g COST vs* PRODUCT evaluation 

techniques than ever before* Costs are being matched with programs and 

budgets are being 'Cut or raised based on these projected program costs. 

.Everyone feels the pressures of optimizing classroom, building, faculty, 

* 

and staff resources* Registrars are thus* becoming more aware of vacant 
seats in the 'various programs and realize that classroom seats are yery 
much like airline seats. If they are not filled at the time of take-off 

4 ^ 

Jtthey are lost forever .... A perishable product. On-line Admissions and . 
Registration procedures are then only a means to redyce the number of seats 
that perish each semester because of sluggish admissions or untimely reporting, 
^ jwkth all its beauty comes the thorn ... the possibility of data loss 

duringl en masse On-line^1legistration* The success of the system will, 

— - ]> 
therefore, depend upon the reliability of the Data Base. 

This paper discusses, a relatively simple Data Base structure which 
allows 6n-line Admissions ^nd Registration. The Data Base keys on. social ^ 
seQurity^ number and permits complete permanent records to be added and 
maintained while students are being registered in classes. 

V ■ ^ ■ - 

2. THE WtER file DILEMMA ' 

In mant instances qualified applicants walk in with application in hand 

t 

only hours batore the registtatiofi process is to close. In an effort to serve 
the prospective student as well as eliminate those perishable seats it is 
necessary to perform the following, c 
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2> THE MASTER FILF DILEMMA (Contiinued) 



• * (X) Accept the application (if possible) 

» (]5) Inform the student ^ to registration procedures 
(issue time-card, etc.) 

(C) Code application 

(D) Enter application on system 
(8) Register student. 

It is at this points that most ofl the managers *of Data Processing who 

are running On-line shops, (all input into the system coming from On-line 

applications) have faced a problem which migTit fee called the ''Master File 

' Dilemm^L". briefly stated as follows. . 

(A) Is it best to add records On-line to the Master File 
and risk loss of data 

OR 

(B) Capture the data and run in batch mode after thefOn-line 
systeln is down. 

Obviously the second techidque is the safest, but what about those 
late applicants and those empty^ seats in the classroom? 

In. order to safely add records and quickly retrieve them, we felt 
standard Indexed Sequential Access Method had to go. It was mida too. slow 
in adding records during heavy Admissions and was none too predictable. 
The new access metU^l^^ttSj^ore muSt: 

(A) Add neajf/ students On-line and in batch mode sii^jflsineously. 

(B) * Have a quick response time. ^ 

(C) Handle multiple riecords -per student. 

(D) Handle multiple files. * ' ' • 

(E) .Utili^.e th^ 'present SMF concept. v 

(F) Be acc^^sil^e sequentially. 

(G) Be easy to maintain* 



3. THE BASIC RECORD DESIGN . ■ . / 

Any Institution which; attempts to maintain a complete permanent 

record Onrllne must allow for new'^ecords to be added as transcripts 
i • ^ ' 

*, i , 

are evaltiated and/or classwbrk Is completed. Good Data Base design, 

therefore, should provide* for quick random additions to the file during 

those very volatile periods of late Admissions and Registration, 

3. 1 The Social Security_ (t)r Student Number) Appendage ^ One easy method 

of allowing multiple records per student is simply extending the student 

number by two charact^s*. These last two characters can be given special 

meaning sucl^ as: !> . ' 

Social Security Number -f '00* •« Vital Stat* 
Social Security^i '05' = College Transfer 

'Social SecuritJ"^ , • -f '59' « J'irst ' Barollment, 

*£ee Table I for Data Elements. 

(NOTICE: Each of the records above '05' have seven logical sub-records.) 

^ ' ' - 

3^2 The Key File . The Kfey Filo is a- relative record file developed to 
allow for the collisions Vln randomizing the social security number. The 
basic 8(&ial security number^is in the form ' AAA-XX-NNNN' where NNNN is a 
fairly sequential numbei?^ The algorithm for finding the key block is as 
'follows: : 

(A) Take the ylast four digits of the S.SJ. 
/(B) If greater than 5000 subtract 5000 from the value. 
(C) Take th^ result from (B) and read that key block. 

J 

Each key block is, separated into ten ^ub-records of 44 bytes each. 
Each key block will allow ten collisions on same number and eleven record 
for each student. 
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3.3 The On-Llne Master , Aftet the sequential master has been loaded to 
disk a common overflow area of blank records is provided after the last 
master record. The relative recoiTd location of this first blank record 
is recorded oti the ke^ file^^nder .the number '000000000'. Any records 
that are added are added in the next blank record on the file.. 

3.4 The Tag- Along Key . To increase response time only one access pf tbe 
key file is required for each'^'series of reads rewrites, for a student^ 
After the current key' block is located it is appended to the last record 
read. In doing this the keys become core resident and pointers to pvery 
record under each "student are available to the Data Management routine* 



CORE RESIDEMT RECORD 

DATA RECORD 



I KEYS 



W Bites 



^14 PiTES 



Any additional read or rewrite for this student requires one 'master 

file access only * ^ . * , - 

The p^w recc^rd add command requires t:he following sequence of 1/0' s: 




Read key for record 000-00-0000. 
Pick up tiext overflow pointer. 

(C) Read next overflow record. ; 

(D) Recori^hould be blank. 

' (E) Add r-ecord to Master File., 

(F) Update next overflow pointer. 

(G) Re-write 000-00-0000 key record. 

(H) Re-write studjsnt record key block. 
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4> . THE COURSE MASTER RECORD ' * ' / ^ 

The Course Haster Pile resides within the 6ame physical Disk area aS, 
the Basic Student Master File. A common overflow area is shared by "all 
files within the Data Base. All access to the Course Master is then a 
fou5 byte rjurilber called "ZAP". The only difference is the access between ^ 
the Course Master and Student Master, is the algorithm jus ed for finding the 
key block. ^ 

(A) Take right three byte^ of Zap Number. 

(E) Add 5000. ' • ^ 

NOTICE: All key blocks for students range from 1 tQ 49'99* Key blocks for 
the Course Master range from 5000 to 5999.' 

5*. THE FINAL TEST 

The final test of an On-line Admissions and Registration Sy5t^ psually 
occurs during the heat of registration when every terminal dedicated to 
registration is backlogged; when the Accounting Office wants their monthly 
reports; when the Personnel'^Of f ice wants a payuoll run; and when the C.£. 
wants the system "for just a few minutes". It is during these times that 
complete confidence in the Data Base is the best llx available foi**;the Data 
Processing. staff. ^ 

Do n<?t be misled in believing that a good solid Data Base will automatically 
insure a good On-line system. The overall system will only be as innovative 
as the application programs which access the data. The implementation of 
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5, THE FINAL^ TEST (continued) ^ ^ . > 

successfiil On-line systems rest on the dogged determination ta'make them 

succeed. This is quite unlike the man described by Benjamin Franklin: 

like the man who, In buying -an ax of a siiith, 
my neighbor desired to have the whole of it's surface as 
• bright as the edge. The s^th consented to grind it bright *: 
^ for him ff he would turn the wheel; he turned, while the * 
smith pressed |the broad face of th^ ax hard and heavily on 
the stone, which ma'de the turning, of it very fatiguing. 
The man came every now and then from the wheel to see how 
the work, went I on, and at length would take his ax as it was, 
without further grinding. , 

"No", skid the smith, "Turn on, tur'n on; we shall have 
it bright by and by; as yet, it is only speckled." "Yes", 
says the-inan, "but I think I like a speckled ax best." Vs, 

If the word "speckled" adequately describes the On-line system at 
your institution the fault may well be in the reliability and responsiveness 
of the Data Base. 
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ITEM FIELD DESCRIPTION 



SPACES POSITION FORM 



1 


Paid or delete flag / . 


>i ■ 


1 


' 2 . 


Social Security Numbers » 
Key Field ^ 


9 


2-10 . 


3 


. -2'. 


U-12 . 


4 


Student Narae^ ^ ^ 


19 


13-31 


5 - 


. ^Street Address' ^ , ^ 


20 


•32-51 


V. 6 


City Name , 


11 


52-62 


7 


State ^(from code taWe) v 


2 


63-64 


8 


• Zip Code ^ \ . / 


5 


• 65-69 


9 


Residency -(countyT 


3 ■ 


70-72 


lo- 


Residency Ostate^ 


2 ^ 


73-74 


ll 


.College Home Phone 


7 


75-81 


12 


Next of Kin Honve Phone 


10 


82-91 


13 


.Next of Kin * * 


19- 


92-110 


1* 


. Relationship 


1 


111 


15 


Next of Kin. Stfteet Address 


20 


112-131 


16 


Next of Kin City Address 


11 


132-142 


^ 17 


Next of Kin State Code 


2 


143-144 


18 


Next o£. Kin Zip 


3 


145-149 


19- 


Date Of Birth . ' 


6 


150-155 


20 


Place of Birth City 


11 


156-L66 


21 


Place of Birth State ^ 


2 


167-168. 


22 


Marital Status 


1 ' 


169, 


23 


Major Interest . 


3 


170-172 


24 


Campus Code * 


1 


173 c 


25 


Citizenship Code 


3 


^ 174-176 


26 


Term of Entrance 


3 


177-1>9 


27 


Attendance 


1 


180 


28 


F/T-P/T 


1 


18L 


29 


Filler 


1 


182 


30 


H^S. Grad, tr.ans, GED, Ind. App. ^ 


1 


183 


31 


Date of Graduation 


4 


184-187 


. 32 


Name of High School 


16 


188-203 


33 


City of High Sch^jol 


11 


204-214 


34 


County of High School 


3 


215-217 


35 


. State of High School 


2 


218-219 


36 


l^ller • 


2 


220-221 


37 


ACT Scores 


10 


222-231 


38 . 


Sex 


1 


232 


. 39 


Race ^ 




233. 


40 






234-235 


41 


Veteran 


i\ 


236 


42 


Filler 


' 11 ^ 


237-247* 


43 / 


Filler Hold Codes 


1 


248 


44 


Future College 


2 ' 


249-250 


45 


Filler -Highest ^Degree Earned 


1 


251 


46 


Filler -Desired Degree 


1 


252 


47 


Grad. Cand. 


1 


253 


48 


Hrs. Employed 


1 


254-255 


49 


Filler 


1 


256 


50 1 


, Residence Code 


1 


257 


51/ 


Date Application Received 


• 6 




52 


$5 Fee (Date Received) >c 


6 


264-269 


53 


Date Major Changed 


6 


270-275 


54 * 


ACT (Date Received) 


6 


276-281 
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applic. 

generated 

applic. 
tt 



tt 
tt 
tt 
tJ 
tt 
tt 
tt 
tt 
tf 
tt 

tr 
tf 
It 
tt 
tt 



Admissions ^ 
Computer Ctr. 
Admissions 

tt 



tt 
t* 



ti 
tt 
•tt 
tt 
tt 
tt 
tt 



Stat. card 

^PPkvise. 

applic: 

applic. 

applic. 

^Pilnerated 



Registration 

Adm. -Advise' 

Admissions 
tt < 



Adm.&Com. Ctr^ 
tt ' ♦ 



applic^ Admissions 
tt ; , tt 



tt 
tt 
tt 
ti 



Adm&ACT 
Applic. 
Stat .card 



. Adm. & Advise 
Admissions 
Registration 



Vet. Off ice Vet., claims 

^tat.card -Registration ' 

Stat .^ard Re gi s t r a t ion 

applic. Admissions 
II f 

advisement Advisjament 
ACT cgtgs ' " & Admv , 
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COimSE MASTER. FILE 



ITEM FIELD DESCRIPTION 



( SPACES ^ POSITION FORM 



.OFFICE' 



1 Flag , - 

2 2A? ' 

3 Key 

4 Dept. & Course*^^^ 

•5 Standard Course Abbreviation 

6 ' Building & Room ^ 

7 Days of Week 

8 ^ Meeting time of classes 
.9- Building & Room 2 

10 Days of Week 2 

11 Mee;ting times of classes 2 
1'2 Hours Credit 

13 Hours Lecture ^ . 

14 Hours Lal> 

15 Fee Code 

, 16 * Amount of Fee 

17 Lab Req, , ' 

18 , Semester Year 

19 Campus 

20 NCHEMS cod^ if 

21 ' Fund 

22 Class Limit 

23 Class Count • 

24 Instructor Name - Last First 

25 Instructor Social Security 

26 ^ Blank 

27 Filler 

28 Itlvision * . 

29 " CWF Tally% ^ 

30 Repeat Code 

31 Number of Weeks 

32 Filler 



(l^st 4 digits) 



.1 


• 1 


A 


2-5 


2 


6-7 


7 


8-14 


14. . 


15-28. 


6. 


29-34 . 


7 ' 


- 35^41 


8 


4Z-49 


6 


50-55 


7 


56-62 


% 


• 63-70 


2 


71-72 


2 


73-74 


2 


75i-76 


1 


77 


2 


' 78-79 


1 


80 


3 


81-83 ■«. 


i ' 


"84 


6 


85-9jj 


1 


91 


3 


92-94 


3 


95-97 


15 


98-112 


9 


"113-121 . 


1 


122 


2 


123-124 


1 


125. 


3 


126-128 


1* 


129 


2 ; 


130^131 
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132-440 



SemSch^dule Academic Dean 



ft 

41 

It 

II " 

II 
*ll 

It 

tl 

II 

ft 

It 



Bus. Office 

SemSchedule Academic Dean 
II • * 

It 

ii ' 



•II 
•I 

It 

♦ > 

generated Adm«*-Re^ 

SemSchedule 
tl 



